ਲੱਖਾਂ 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 ਵਿੱਚ fold ਕਰਦਾ ਹੈ। Output ਹਰ (minute, dimension) ਲਈ ਇੱਕ pre-aggregated row ਹੈ।
- **OLAP store (ClickHouse, Druid, Pinot)** ਉਹਨਾਂ rollups ਨੂੰ columnar store ਕਰਦਾ ਹੈ। "ਪਿਛਲੇ 24h ਦੀ revenue" query ਕਰਨ ਵਾਲਾ ਇੱਕ dashboard ~1,440 rows scan ਕਰਦਾ ਹੈ, ਲੱਖਾਂ ਨਹੀਂ — sub-second।
- **Materialized views** ClickHouse ਵਿੱਚ ਓਹੀ rollup DB ਦੇ ਅੰਦਰ (`AggregatingMergeTree`) ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਤੁਸੀਂ ਘੱਟ moving parts ਚਾਹੁੰਦੇ ਹੋ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਪਰਖਦਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ **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 (ਤੇਜ਼ ਪਰ approximate) ਦੇ ਨਾਲ-ਨਾਲ ਚਲਾਉਂਦਾ ਹੈ — 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 ਬੰਦ ਹੋਣ ਬਾਅਦ ਆਉਂਦਾ ਹੈ। Watermarks + allowed-lateness windows ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹਦੇ ਹਨ, ਜਾਂ ਇੱਕ nightly batch job ਕੱਲ੍ਹ ਦੇ numbers ਠੀਕ ਕਰਦਾ ਹੈ।
- **Multi-currency / refunds** ਨੂੰ signed events ਵਜੋਂ model ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ "revenue" ਭਟਕ ਜਾਂਦੀ ਹੈ।
- **ਕਦੋਂ ਨਹੀਂ:** ਕੁਝ ਹਜ਼ਾਰ txns/ਦਿਨ ਨੂੰ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਚਾਹੀਦਾ — ਇੱਕ cron ਦੁਆਰਾ update ਕੀਤੀ Postgres rollup table ਓਸ Kafka+Flink cluster ਨੂੰ ਹਰਾ ਦਿੰਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਨੂੰ operate ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਆਰਕੀਟੈਕਚਰ

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

ਸੰਬੰਧਿਤ ਸਵਾਲ