दररोज लाखो 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** (per minute/hour) ठेवतो आणि प्रत्येक event त्याच्या **state store** मधील running total मध्ये folds करतो. Output प्रति (minute, dimension) एक pre-aggregated row आहे.
- **OLAP store (ClickHouse, Druid, Pinot)** ते rollups columnar साठवते. "शेवटच्या 24 तासांचे revenue" query करणारे dashboard लाखो नव्हे तर ~1,440 rows scan करते — sub-second.
- **Materialized views** ClickHouse मध्ये कमी moving parts हवे असल्यास DB आत तेच rollup करू शकतात (`AggregatingMergeTree`).

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्ही **write वर pre-aggregate vs read वर scan** करता का, आणि तुम्हाला **exactly-once** समजते का हे तपासतो. चांगली उत्तरे Kafka + OLAP नावाने सांगतात; उत्तम उत्तरे **late/duplicate events totals का corrupt करतात** आणि ते कसे fix करावे हे समजावतात: idempotent keys, exactly-once साठी Flink **checkpointing + transactional sink**, आणि late arrivals असूनही windows बंद करण्यासाठी **watermarks**. एक सामान्य सापळा म्हणजे Postgres वर `SELECT SUM()` सुचवणे — दररोज हजारांवर ठीक, लाखांवर कोसळते.

## तडजोडी आणि अपयश

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

आर्किटेक्चर

कसे कार्य करते

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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