Architecture decision · fintech
ClickHouse reporting and analytics service for a B2B payments platform
Backend / PlatformQuality + Knowledge ClickHouseKafkaGoPostgreSQL
billing · payments · crypto ──► Kafka ──► ClickHouse ──► reporting API ──► metrics & dashboards
PostgreSQL (OLTP) ── transactional path, fully isolated from analytics Problem
A B2B payments platform needed aggregation, analytics, and metrics over growing operational data; running analytical queries on the transactional PostgreSQL database was slow and put the payment path at risk.
Approach
Architected a dedicated reporting service on ClickHouse with event ingestion via Kafka, designed pre-aggregation schemas for the query patterns the business actually needed, and tuned both PostgreSQL and ClickHouse (partitioning, connection pooling) for analytical workloads.
Result
A reporting system that serves analytics and metrics without touching the transactional path — cutting report generation from ~30s on PostgreSQL to under 2s on ClickHouse, and staying fast as volume grew past 1M+ events/day.
Evidence
Described in work history (Korvax, 2022–present); architecture walkthrough available in a call.
Available for: private walkthrough
The key decision was separating analytical workloads from the transactional database entirely: events flow through Kafka into ClickHouse, where pre-aggregation schemas are shaped to the query patterns the business actually runs — so reporting scales independently of payments.