reports र ML का लागि high-volume event-tracking pipeline डिजाइन गर्नुहोस् — कुन stack?

Question

IT Interview Practice · Accepted Answer

दैनिक करोडौं events (~प्रति सेकेन्ड केही हजार, peaks मा बढी) मा जित्ने चाल भनेको ingestion लाई serving बाट decouple गर्नु हो: writes लाई एउटा durable log मा absorb गर्नुहोस्, stream लाई एकपटक process गर्नुहोस्, र विपरीत jobs का लागि tuned दुई stores मा fan out गर्नुहोस् — parents का लागि pre-aggregated (fast reads), ML का लागि raw र full-fidelity।

एउटा mailroom — collector ले mail प्राप्त गर्छ, Kafka conveyor belt हो, र प्रत्येक item दुई shelves मा copy गरिन्छ: parents एक झलक हेर्ने , र ML team ले खोतल्ने ।

**Mental model:** एउटा mailroom — collector ले mail प्राप्त गर्छ, Kafka conveyor belt हो, र प्रत्येक item दुई shelves मा copy गरिन्छ: parents एक झलक हेर्ने *summary board*, र ML team ले खोतल्ने *full archive*।

## 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
// एउटा consumer ले Kafka एकपटक read गर्छ र दुवै 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 लागू गर्नुहोस् ताकि 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 ले तत्काल reads दिन्छ तर dimensions अगावै fix गर्छ; raw lake flexible छ तर ढिलो। **दुवै** राख्नुहोस् — classic write-once, read-many split।

Write path (ingest)

Read path (serving)

Stack & why

Interview lens

Trade-offs

सम्बन्धित प्रश्नहरू