రోజుకు millions of 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 ను read చేస్తాయి.** రోజుకు millions of txns వద్ద మీరు ప్రతి page load పై raw table పై `SUM()` ను ఎప్పుడూ run చేయరు — మీరు 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 ను rebuild చేయడానికి history ను **replay** చేయనిస్తుంది.
- **Stream processor (Flink / Kafka Streams)** **tumbling/sliding windows** (per minute/hour) ను ఉంచి ప్రతి event ను తన **state store** లో running total లోకి fold చేస్తుంది. Output ఒక్కో (minute, dimension) కి ఒక pre-aggregated row.
- **OLAP store (ClickHouse, Druid, Pinot)** ఆ rollups ను columnar గా store చేస్తుంది. "revenue last 24h" ను query చేసే dashboard millions కాదు, ~1,440 rows ను scan చేస్తుంది — sub-second.
- ClickHouse లో **Materialized views** తక్కువ 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 ను close చేయడానికి **watermarks**. సాధారణ ఉచ్చు Postgres పై `SELECT SUM()` ప్రతిపాదించడం — thousands/day వద్ద బాగుంటుంది, millions వద్ద కుప్పకూలుతుంది.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్యాలు

- **Lambda vs Kappa.** Lambda ఒక batch layer (nightly Spark source of truth ను reconcile చేస్తుంది) ను stream layer (వేగవంతమైన కానీ approximate) పక్కన run చేస్తుంది — accurate కానీ రెండు codebases. **Kappa** stream layer ను మాత్రమే వాడి bugs ను fix చేయడానికి **Kafka ను replay చేస్తుంది** — సరళం, ఒక codebase, ఇప్పుడు సాధారణ default.
- **Exactly-once ఉచితం కాదు.** Transactional sinks latency మరియు throughput cost ను జోడిస్తాయి; అనేక teams బదులుగా **at-least-once + `txn_id` ద్వారా keyed idempotent upserts** ను అంగీకరిస్తాయి.
- **Late data.** 2h ఆలస్యంగా settle అయ్యే ఒక payment దాని window close అయిన తర్వాత లాండ్ అవుతుంది. Watermarks + allowed-lateness windows ను తిరిగి తెరుస్తాయి, లేదా ఒక nightly batch job నిన్నటి సంఖ్యలను correct చేస్తుంది.
- **Multi-currency / refunds** ను signed events గా model చేయాలి, లేకపోతే "revenue" drift అవుతుంది.
- **ఎప్పుడు కాదు:** రోజుకు కొన్ని వేల txns కి ఇదేమీ అవసరం లేదు — cron ద్వారా update అయ్యే ఒక Postgres rollup table మీరు operate చేయాల్సిన Kafka+Flink cluster ను ఓడిస్తుంది.

ఆర్కిటెక్చర్

ఇది ఎలా పనిచేస్తుంది

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్యాలు

సంబంధిత ప్రశ్నలు