લાખો transactions/day પર real-time revenue analytics: કેવી રીતે?

Question

IT Interview Practice · Accepted Answer

**transactions ને Kafka દ્વારા એક stream processor માં stream કરો જે OLAP store માં pre-aggregate કરે, જેથી dashboards raw events scan કરવાને બદલે tiny pre-computed rollups વાંચે.** લાખો txns/day પર તમે ક્યારેય દરેક 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 (`amount`, `currency`, `ts`, `merchant`) publish કરે છે. તે spikes buffer કરે છે, producers ને consumers થી decouple કરે છે, અને aggregates rebuild કરવા તમને 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 સ્ટોર કરે છે. "revenue last 24h" query કરતું dashboard લાખો નહીં, ~1,440 rows scan કરે છે — sub-second.
- ClickHouse માં **Materialized views** DB ની અંદર જ એ જ rollup કરી શકે છે (`AggregatingMergeTree`) જો તમે ઓછા moving parts ઇચ્છો.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર probe કરે છે કે તમે **write પર pre-aggregate vs read પર scan**, અને શું તમે **exactly-once** સમજો છો. Good answers Kafka + OLAP નું નામ આપે છે; great answers સમજાવે છે કે **late/duplicate events totals ને શા માટે corrupt કરે છે** અને તેમને કેવી રીતે ઠીક કરવા: idempotent keys, exactly-once માટે Flink **checkpointing + transactional sink**, અને late arrivals છતાં windows બંધ કરવા **watermarks**. એક સામાન્ય trap એ Postgres પર `SELECT SUM()` પ્રસ્તાવવો — હજારો/day પર ઠીક, લાખો પર તૂટી પડે.

## Trade-offs અને failure

- **Lambda vs Kappa.** Lambda stream layer (ઝડપી પણ approximate) ની બાજુમાં એક batch layer (nightly Spark source of truth ને reconcile કરે) ચલાવે છે — accurate પણ બે 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.** 2h મોડું settle થતું payment તેની window બંધ થયા પછી land થાય છે. Watermarks + allowed-lateness windows ને ફરી ખોલે છે, અથવા એક nightly batch job ગઈકાલના numbers correct કરે છે.
- **Multi-currency / refunds** ને signed events તરીકે model કરવા જ પડે, નહીંતર "revenue" drift થાય.
- **ક્યારે ન કરવું:** થોડા હજાર txns/day ને આમાંનું કંઈ જોઈતું નથી — cron દ્વારા update થતું Postgres rollup table તમારે operate કરવા પડતા Kafka+Flink cluster કરતાં સારું છે.

આર્કિટેક્ચર

તે કેવી રીતે કામ કરે છે

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો