reports اور ML کے لیے ایک high-volume event-tracking pipeline ڈیزائن کریں — کون سا stack؟

Question

IT Interview Practice · Accepted Answer

روزانہ کروڑوں events (تقریباً چند ہزار فی سیکنڈ، peaks پر زیادہ) پر جیتنے والی حکمتِ عملی یہ ہے کہ ingestion کو serving سے decouple کریں: writes کو ایک durable log میں جذب کریں، stream کو ایک بار process کریں، اور اسے دو ایسے stores کی طرف fan out کریں جو مخالف کاموں کے لیے tuned ہوں — والدین کے لیے pre-aggregated (تیز reads)، اور ML کے لیے raw اور full-fidelity۔

ایک mailroom — collector ڈاک وصول کرتا ہے، Kafka conveyor belt ہے، اور ہر چیز دو shelves پر copy کی جاتی ہے: ایک جسے والدین ایک نظر دیکھتے ہیں، اور ایک جسے ML team کھنگالتی ہے۔

**ذہنی ماڈل:** ایک mailroom — collector ڈاک وصول کرتا ہے، Kafka conveyor belt ہے، اور ہر چیز دو shelves پر copy کی جاتی ہے: ایک *summary board* جسے والدین ایک نظر دیکھتے ہیں، اور ایک *مکمل archive* جسے ML team کھنگالتی ہے۔

## Write path (ingest)

```text
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup  (daily summaries)
 (learning app)    (HTTP)     (buffer,   (read once)  └─▶ S3 / Parquet (raw events)
                              replay)
```

- **Collector** HTTP پر **batched** events لیتا ہے — client پر batching کروڑوں چھوٹے writes کو بہت کم requests میں بدل دیتی ہے۔
- **Kafka** durable buffer ہے: یہ spikes جذب کرتا ہے، producers کو consumers سے decouple کرتا ہے، اور جب ML کوئی feature شامل کرے یا آپ نیا rollup متعارف کرائیں تو آپ کو history **replay** کرنے دیتا ہے۔
- **Stream processor** Kafka کو ایک بار پڑھتا ہے اور دونوں sinks میں لکھتا ہے — raw کو lake میں append کریں، reports کے لیے rollups upsert کریں۔

```js
// ایک consumer Kafka کو ایک بار پڑھتا ہے اور دونوں sinks میں لکھتا ہے
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // raw -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// aggregate -> OLAP (reports)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## Read path (serving)

```text
Parent app ─▶ API ─▶ OLAP rollup                 (pre-aggregated: report = O(1), no scan)
ML / Data  ─▶ Spark / warehouse ─▶ S3 / Parquet  (raw, flexible, ad-hoc)
```

والدین **pre-aggregated summaries** تک پہنچتے ہیں، لہٰذا ایک report صرف ایک key lookup ہے، کبھی اربوں rows پر scan نہیں۔ ML **raw lake** سے query کرتا ہے، feature engineering کے لیے ہر field محفوظ رکھتا ہے۔

## Stack اور کیوں
- **Kafka** — buffer، decouple، replay۔
- **ClickHouse / روزانہ summary tables** — والدین کے dashboards کے لیے read-optimized۔
- **S3 + Parquet** — سستا، columnar، لچکدار raw storage برائے ML۔
- **Schema registry** — event contract نافذ کریں تاکہ producers خاموشی سے consumers کو نہ توڑ سکیں۔

## انٹرویو کا زاویہ
انٹرویو لینے والا جانچتا ہے کہ کیا آپ **write-optimized ingest کو read-optimized serving سے** الگ کرتے ہیں، ہر والدین کی report کے لیے raw events کو scan کرنے سے بچتے ہیں، اور ML کے لیے raw data رکھتے ہیں۔ **کمزور:** "سب کچھ Postgres میں ڈال دیں اور query کریں۔" **مضبوط:** durable buffer + دو serving paths + replay + ایک schema contract، اور scale کا احساس۔

## Trade-offs
Pre-aggregation فوری reads دیتی ہے مگر dimensions کو پہلے سے طے کر دیتی ہے؛ raw lake لچکدار مگر سست ہے۔ **دونوں** رکھیں — کلاسک write-once, read-many تقسیم۔

Write path (ingest)

Read path (serving)

Stack اور کیوں

انٹرویو کا زاویہ

Trade-offs

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