reports ਅਤੇ ML ਲਈ ਇੱਕ high-volume event-tracking pipeline ਡਿਜ਼ਾਈਨ ਕਰੋ — ਕਿਹੜਾ stack?

Question

IT Interview Practice · Accepted Answer

ਹਰ ਦਿਨ ਕਰੋੜਾਂ events (~ਕੁਝ ਹਜ਼ਾਰ/sec, peaks 'ਤੇ ਜ਼ਿਆਦਾ) 'ਤੇ ਜਿੱਤਣ ਵਾਲੀ ਚਾਲ ਹੈ **ingestion ਨੂੰ serving ਤੋਂ ਵੱਖ ਕਰਨਾ**: writes ਨੂੰ ਇੱਕ durable log ਵਿੱਚ absorb ਕਰੋ, stream ਨੂੰ **ਇੱਕ ਵਾਰ** process ਕਰੋ, ਅਤੇ **ਦੋ ਉਲਟ ਕੰਮਾਂ ਲਈ tuned stores** ਵਿੱਚ fan out ਕਰੋ — parents ਲਈ pre-aggregated (fast reads), ਅਤੇ ML ਲਈ raw ਅਤੇ full-fidelity।

**Mental model:** ਇੱਕ mailroom — collector ਡਾਕ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, Kafka conveyor belt ਹੈ, ਅਤੇ ਹਰ item ਦੋ shelves 'ਤੇ copy ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਇੱਕ *summary board* ਜਿਸ 'ਤੇ parents ਨਜ਼ਰ ਮਾਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ *full 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 absorb ਕਰਦਾ ਹੈ, producers ਨੂੰ consumers ਤੋਂ decouple ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ML ਕੋਈ feature ਜੋੜਦੀ ਹੈ ਜਾਂ ਤੁਸੀਂ ਨਵਾਂ rollup ਲਿਆਉਂਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ history **replay** ਕਰਨ ਦਿੰਦਾ ਹੈ।
- **Stream processor** Kafka ਨੂੰ ਇੱਕ ਵਾਰ read ਕਰਦਾ ਹੈ ਅਤੇ ਦੋਵੇਂ sinks ਵਿੱਚ ਲਿਖਦਾ ਹੈ — raw ਨੂੰ lake ਵਿੱਚ append ਕਰੋ, reports ਲਈ rollups ਨੂੰ upsert ਕਰੋ।

```js
// One consumer reads Kafka once and writes BOTH 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)
```

Parents **pre-aggregated summaries** ਨੂੰ hit ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ report ਇੱਕ key lookup ਹੁੰਦੀ ਹੈ, ਅਰਬਾਂ rows ਉੱਤੇ scan ਕਦੇ ਨਹੀਂ। ML **raw lake** ਨੂੰ query ਕਰਦੀ ਹੈ, feature engineering ਲਈ ਹਰ field ਨੂੰ ਰੱਖਦੀ ਹੈ।

## Stack & why
- **Kafka** — buffer, decouple, replay।
- **ClickHouse / daily summary tables** — parent dashboards ਲਈ read-optimized।
- **S3 + Parquet** — ML ਲਈ ਸਸਤਾ, columnar, flexible raw storage।
- **Schema registry** — event contract ਨੂੰ enforce ਕਰੋ ਤਾਂ ਜੋ producers ਚੁੱਪ-ਚਾਪ consumers ਨੂੰ break ਨਾ ਕਰ ਸਕਣ।

## Interview lens
Interviewer ਪਰਖਦਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ **write-optimized ingest ਨੂੰ read-optimized serving ਤੋਂ ਵੱਖ** ਕਰਦੇ ਹੋ, ਹਰ parent report ਲਈ raw events scan ਕਰਨ ਤੋਂ ਬਚਦੇ ਹੋ, ਅਤੇ ML ਲਈ raw data ਰੱਖਦੇ ਹੋ। **ਕਮਜ਼ੋਰ:** "ਸਭ ਕੁਝ Postgres ਵਿੱਚ ਪਾਓ ਅਤੇ query ਕਰੋ।" **ਮਜ਼ਬੂਤ:** durable buffer + ਦੋ serving paths + replay + ਇੱਕ schema contract, scale ਦੀ ਸਮਝ ਦੇ ਨਾਲ।

## Trade-offs
Pre-aggregation instant reads ਦਿੰਦਾ ਹੈ ਪਰ dimensions ਨੂੰ ਪਹਿਲਾਂ ਹੀ fix ਕਰ ਦਿੰਦਾ ਹੈ; raw lake flexible ਹੈ ਪਰ ਹੌਲੀ। **ਦੋਵੇਂ** ਰੱਖੋ — ਕਲਾਸਿਕ write-once, read-many ਵੰਡ।

Write path (ingest)

Read path (serving)

Stack & why

Interview lens

Trade-offs

ਸੰਬੰਧਿਤ ਸਵਾਲ