reports आणि ML साठी high-volume event-tracking pipeline डिझाइन करा — कोणता stack?

Question

IT Interview Practice · Accepted Answer

दररोज शेकडो दशलक्ष events/day (~काही हजार/sec, peaks ला जास्त) या प्रमाणात विजयी चाल म्हणजे ingestion ला serving पासून decouple करणे: writes एका durable log मध्ये शोषून घ्या, stream एकदाच process करा, आणि विरुद्ध कामांसाठी tuned केलेल्या दोन stores मध्ये fan out करा — parents साठी pre-aggregated (fast reads), ML साठी raw आणि full-fidelity.

एक mailroom — collector मेल घेतो, Kafka हा conveyor belt आहे, आणि प्रत्येक वस्तू दोन shelves वर copy होते: एक जो parents नजर टाकतात, आणि एक ज्यात ML team खोदून पाहते.

**Mental model:** एक mailroom — collector मेल घेतो, Kafka हा conveyor belt आहे, आणि प्रत्येक वस्तू दोन 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 शोषून घेतो, producers ला consumers पासून decouple करतो, आणि ML feature जोडते किंवा नवीन rollup आणता तेव्हा history **replay** करू देतो.
- **Stream processor** Kafka एकदाच वाचतो आणि दोन्ही sinks मध्ये लिहितो — lake मध्ये raw 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 तोडू शकत नाहीत.

## 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 पण slow आहे. **दोन्ही** ठेवा — classic write-once, read-many split.

Write path (ingest)

Read path (serving)

Stack & why

Interview lens

Trade-offs

संबंधित प्रश्न