ஒரு நாளைக்கு மில்லியன் கணக்கான 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** (ஒரு நிமிடம்/மணி) வைத்து ஒவ்வொரு 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.
- ClickHouse-இல் **Materialized views** குறைவான moving parts வேண்டுமெனில் DB-க்குள்ளேயே அதே rollup செய்யலாம் (`AggregatingMergeTree`).

## நேர்காணல் கண்ணோட்டம்

நீங்கள் **write-இல் pre-aggregate vs read-இல் scan** செய்கிறீர்களா, மேலும் **exactly-once**-ஐ புரிந்துகொள்கிறீர்களா என்பதை நேர்காணல் செய்பவர் ஆராய்கிறார். நல்ல பதில்கள் Kafka + OLAP குறிப்பிடுகின்றன; சிறந்த பதில்கள் **late/duplicate events ஏன் totals-ஐ corrupt செய்கின்றன** என்பதையும் அவற்றை எப்படிச் சரிசெய்வது என்பதையும் விளக்குகின்றன: idempotent keys, exactly-once-க்கு Flink **checkpointing + transactional sink**, மற்றும் late arrivals இருந்தாலும் windows-ஐ மூட **watermarks**. ஒரு பொதுவான பொறி Postgres மீது `SELECT SUM()` முன்மொழிவது — ஒரு நாளைக்கு ஆயிரக்கணக்கில் பரவாயில்லை, மில்லியன்களில் அது சரிகிறது.

## சமரசங்களும் பிழைகளும்

- **Lambda vs Kappa.** Lambda ஒரு batch layer-ஐ (nightly Spark source of truth-ஐ reconcile செய்கிறது) stream layer-க்குப் பக்கத்தில் இயக்குகிறது (வேகமானது ஆனால் தோராயமானது) — துல்லியமானது ஆனால் இரண்டு codebases. **Kappa** stream layer-ஐ மட்டும் பயன்படுத்தி bugs-ஐச் சரிசெய்ய **Kafka-ஐ replay** செய்கிறது — எளிமையானது, ஒரு codebase, இப்போது பொதுவான default.
- **Exactly-once இலவசம் அல்ல.** Transactional sinks latency மற்றும் throughput cost சேர்க்கின்றன; பல குழுக்கள் மாறாக `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-ஐ வெல்கிறது.

கட்டமைப்பு

எப்படி வேலை செய்கிறது

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் பிழைகளும்

தொடர்புடைய கேள்விகள்