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 કરો, અને વિરોધી કામ માટે tuned બે stores માં fan out કરો — parents માટે pre-aggregated (fast reads), ML માટે raw અને full-fidelity.

એક mailroom — collector મેઇલ મેળવે છે, Kafka એ conveyor belt છે, અને દરેક item બે shelves પર copy થાય છે: એક જે parents એક નજરે જુએ, અને એક જેમાં ML team ખોદકામ કરે.

**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 ને એક વાર વાંચે છે અને બંને sinks માં લખે છે — lake માં raw 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)
```

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 છે પણ ધીમું છે. **બંને** રાખો — classic write-once, read-many split.

Write path (ingest)

Read path (serving)

Stack & why

Interview lens

Trade-offs

સંબંધિત પ્રશ્નો