Günde milyonlarca transaction üzerinde gerçek zamanlı gelir analitiği: nasıl?

Question

IT Interview Practice · Accepted Answer

**Transaction'ları Kafka üzerinden, bir OLAP store'a önceden aggregate eden bir stream processor'a stream'leyin, böylece dashboard'lar ham olayları taramak yerine minik önceden hesaplanmış rollup'ları okur.** Günde milyonlarca transaction'da, her sayfa yüklemesinde ham tablo üzerinde asla `SUM()` çalıştırmazsınız — bir kez, yazmada aggregate edersiniz.

## Mimari

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## Nasıl çalışır

- **Kafka** dayanıklı log'dur. Her ödeme bir olay publish eder (`amount`, `currency`, `ts`, `merchant`). Spike'ları buffer'lar, producer'ları consumer'lardan decouple eder ve aggregate'leri yeniden inşa etmek için geçmişi **replay** etmenize izin verir.
- **Stream processor (Flink / Kafka Streams)**, **tumbling/sliding window**'lar (dakika/saat başına) tutar ve her olayı **state store**'undaki bir running total'a katlar. Çıktı, (dakika, dimension) başına önceden aggregate edilmiş bir satırdır.
- **OLAP store (ClickHouse, Druid, Pinot)** o rollup'ları columnar saklar. "Son 24 saatteki gelir"i sorgulayan bir dashboard milyonlarca değil, ~1.440 satır tarar — saniye altı.
- ClickHouse'daki **materialized view**'ler, daha az hareketli parça istiyorsanız aynı rollup'ı DB içinde yapabilir (`AggregatingMergeTree`).

## Mülakat perspektifi

Mülakatı yapan kişi, **yazmada önceden aggregate vs okumada tarama** yapıp yapmadığınızı ve **exactly-once**'ı anlayıp anlamadığınızı yoklar. İyi cevaplar Kafka + OLAP'ı adlandırır; harika cevaplar **geç/duplicate olayların toplamları neden bozduğunu** ve nasıl düzeltileceğini açıklar: idempotent key'ler, exactly-once için Flink **checkpointing + transactional sink** ve geç varışlara rağmen window'ları kapatmak için **watermark'lar**. Yaygın bir tuzak, Postgres üzerinde `SELECT SUM()` önermektir — günde binlerce'de iyi, milyonlarca'da çöker.

## Ödünleşimler & hata

- **Lambda vs Kappa.** Lambda, stream layer'ın (hızlı ama yaklaşık) yanında bir batch layer (gecelik Spark doğruluk kaynağını mutabakat yapar) çalıştırır — doğru ama iki codebase. **Kappa**, yalnızca stream layer'ı kullanır ve bug'ları düzeltmek için **Kafka'yı replay** eder — daha basit, tek codebase, artık yaygın varsayılan.
- **Exactly-once bedava değildir.** Transactional sink'ler latency ve throughput maliyeti ekler; birçok takım bunun yerine **at-least-once + `txn_id` ile anahtarlanmış idempotent upsert**'leri kabul eder.
- **Geç veri.** 2 saat geç settle olan bir ödeme, window'u kapandıktan sonra iner. Watermark'lar + allowed-lateness window'ları yeniden açar veya gecelik bir batch işi dünkü rakamları düzeltir.
- **Multi-currency / refund**'lar signed olay olarak modellenmelidir, yoksa "gelir" kayar.
- **Ne zaman yapılmamalı:** günde birkaç bin transaction bunların hiçbirine ihtiyaç duymaz — bir cron tarafından güncellenen bir Postgres rollup tablosu, işletmeniz gereken bir Kafka+Flink cluster'ından üstündür.

Mimari

Nasıl çalışır

Mülakat perspektifi

Ödünleşimler & hata

İlgili sorular