प्रति दिन लाखों transactions पर real-time revenue analytics: कैसे?

Question

IT Interview Practice · Accepted Answer

**transactions को Kafka के ज़रिए एक stream processor में stream करें जो एक OLAP store में pre-aggregate करता है, ताकि dashboards raw events scan करने के बजाय छोटे pre-computed rollups पढ़ें।** लाखों txns/दिन पर आप कभी हर page load पर raw table पर `SUM()` नहीं चलाते — आप एक बार, write पर aggregate करते हैं।

## आर्किटेक्चर

```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)
```

## यह कैसे काम करता है

- **Kafka** durable log है। हर payment एक event publish करता है (`amount`, `currency`, `ts`, `merchant`)। यह spikes को buffer करता है, producers को consumers से decouple करता है, और आपको aggregates फिर से बनाने के लिए history **replay** करने देता है।
- **Stream processor (Flink / Kafka Streams)** **tumbling/sliding windows** (प्रति minute/hour) रखता है और हर event को अपने **state store** में एक running total में fold करता है। output प्रति (minute, dimension) एक pre-aggregated row है।
- **OLAP store (ClickHouse, Druid, Pinot)** उन rollups को columnar स्टोर करता है। "पिछले 24h का revenue" query करने वाला एक dashboard ~1,440 rows scan करता है, लाखों नहीं — sub-second।
- **Materialized views** ClickHouse में वही rollup DB के अंदर कर सकते हैं (`AggregatingMergeTree`) अगर आप कम moving parts चाहते हैं।

## इंटरव्यू का नज़रिया

Interviewer परखता है कि क्या आप **write पर pre-aggregate बनाम read पर scan** करते हैं, और क्या आप **exactly-once** समझते हैं। अच्छे जवाब Kafka + OLAP नाम लेते हैं; बढ़िया जवाब समझाते हैं कि **late/duplicate events totals को क्यों दूषित करते हैं** और उन्हें कैसे ठीक करें: idempotent keys, exactly-once के लिए Flink **checkpointing + transactional sink**, और windows को बंद करने के लिए **watermarks** भले ही late arrivals हों। एक आम जाल है Postgres पर `SELECT SUM()` प्रस्तावित करना — हज़ारों/दिन पर ठीक, यह लाखों पर ध्वस्त हो जाता है।

## ट्रेड-ऑफ़ और failure

- **Lambda बनाम Kappa.** Lambda एक batch layer (nightly Spark source of truth reconcile करता है) को stream layer (तेज़ पर approximate) के साथ चलाता है — सटीक पर दो codebases। **Kappa** केवल stream layer इस्तेमाल करता है और bugs ठीक करने के लिए **Kafka replay** करता है — सरल, एक codebase, अब आम default।
- **Exactly-once मुफ़्त नहीं है.** Transactional sinks latency और throughput cost जोड़ते हैं; कई teams इसके बजाय `txn_id` से keyed **at-least-once + idempotent upserts** स्वीकार करती हैं।
- **Late data.** एक payment जो 2h देर से settle होता है वह अपनी window बंद होने के बाद आता है। Watermarks + allowed-lateness windows फिर से खोलते हैं, या एक nightly batch job कल के numbers ठीक करता है।
- **Multi-currency / refunds** को signed events के रूप में model करना चाहिए, वरना "revenue" खिसक जाता है।
- **कब नहीं:** कुछ हज़ार txns/दिन को इसमें से कुछ नहीं चाहिए — एक cron द्वारा update की गई Postgres rollup table एक Kafka+Flink cluster को पीट देती है जिसे आपको operate करना पड़ता है।

आर्किटेक्चर

यह कैसे काम करता है

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

संबंधित प्रश्न