روزانہ لاکھوں transactions پر real-time revenue analytics: کیسے؟

Question

IT Interview Practice · Accepted Answer

**transactions کو Kafka کے ذریعے ایک stream processor میں stream کریں جو انہیں پہلے سے aggregate کر کے ایک OLAP store میں ڈالے، تاکہ dashboards خام events scan کرنے کے بجائے چھوٹے پہلے سے compute شدہ rollups پڑھیں۔** روزانہ لاکھوں txns پر آپ ہر page load پر خام 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 دوبارہ بنانے کے لیے تاریخ **replay** کرنے دیتی ہے۔
- **Stream processor (Flink / Kafka Streams)** **tumbling/sliding windows** (per minute/hour) رکھتا ہے اور ہر event کو اپنے **state store** میں ایک running total میں fold کرتا ہے۔ Output فی (minute، dimension) ایک پہلے سے aggregated row ہے۔
- **OLAP store (ClickHouse، Druid، Pinot)** ان rollups کو columnar store کرتا ہے۔ ایک dashboard جو "پچھلے 24h کی revenue" query کرتا ہے تقریباً 1,440 rows scan کرتا ہے، لاکھوں نہیں — sub-second۔
- ClickHouse میں **Materialized views** DB کے اندر وہی rollup کر سکتے ہیں (`AggregatingMergeTree`) اگر آپ کم moving parts چاہتے ہیں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ آپ **write پر pre-aggregate بمقابلہ read پر scan** کرتے ہیں، اور کیا آپ **exactly-once** سمجھتے ہیں۔ اچھے جواب Kafka + OLAP کا نام لیتے ہیں؛ عمدہ جواب بتاتے ہیں کہ **دیر/duplicate events totals کو کیسے خراب کرتے ہیں** اور انہیں کیسے ٹھیک کریں: idempotent keys، exactly-once کے لیے Flink **checkpointing + transactional sink**، اور windows کو دیر سے آمدنیوں کے باوجود بند کرنے کے لیے **watermarks**۔ ایک عام جال Postgres پر `SELECT SUM()` تجویز کرنا ہے — روزانہ ہزاروں پر ٹھیک، لاکھوں پر یہ گر جاتا ہے۔

## توازن اور ناکامی

- **Lambda بمقابلہ Kappa۔** Lambda ایک batch layer چلاتی ہے (رات کا Spark source of truth کو reconcile کرتا ہے) stream layer کے ساتھ ساتھ (تیز مگر تخمینی) — درست مگر دو codebases۔ **Kappa** صرف stream layer استعمال کرتی ہے اور bugs ٹھیک کرنے کے لیے **Kafka replay** کرتی ہے — سادہ، ایک codebase، اب عام default۔
- **Exactly-once مفت نہیں۔** Transactional sinks latency اور throughput لاگت بڑھاتے ہیں؛ بہت سی teams اس کے بجائے `txn_id` سے keyed **at-least-once + idempotent upserts** قبول کرتی ہیں۔
- **دیر سے ڈیٹا۔** ایک payment جو 2h دیر سے settle ہوتی ہے اپنے window بند ہونے کے بعد آتی ہے۔ Watermarks + allowed-lateness windows دوبارہ کھولتے ہیں، یا ایک رات کا batch job کل کے اعداد درست کرتا ہے۔
- **Multi-currency / refunds** کو signed events کے طور پر ماڈل کرنا ہوگا، ورنہ "revenue" بہک جاتی ہے۔
- **کب نہیں:** روزانہ چند ہزار txns کو اس میں سے کچھ نہیں چاہیے — ایک cron سے update ہونے والی Postgres rollup table اُس Kafka+Flink cluster کو مات دیتی ہے جسے آپ کو چلانا پڑے۔

فن تعمیر

یہ کیسے کام کرتا ہے

انٹرویو کا نقطۂ نظر

توازن اور ناکامی

متعلقہ سوالات