Ontwerp een high-volume event-tracking pipeline voor rapporten en ML — welke stack?

Question

IT Interview Practice · Accepted Answer

Bij honderden miljoenen events/dag (~enkele duizenden/sec, hoger bij pieken) is de winnende zet om ingest van serving te ontkoppelen: absorbeer writes in een duurzame log, verwerk de stream één keer, en fan out naar twee stores die voor tegengestelde taken zijn afgestemd — voor-geaggregeerd voor ouders (snelle reads), raw en met volledige detailgetrouwheid voor ML.

een postkamer — de collector ontvangt de post, Kafka is de lopende band, en elk item wordt op twee planken gekopieerd: een waar ouders even naar kijken, en een dat het ML-team doorspit.

**Mentaal model:** een postkamer — de collector ontvangt de post, Kafka is de lopende band, en elk item wordt op twee planken gekopieerd: een *samenvattingsbord* waar ouders even naar kijken, en een *volledig archief* dat het ML-team doorspit.

## 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** neemt **gebatchte** events over HTTP aan — batching aan de clientkant verandert honderden miljoenen kleine writes in veel minder requests.
- **Kafka** is de duurzame buffer: het absorbeert pieken, ontkoppelt producers van consumers, en laat je de historie **replayen** wanneer ML een feature toevoegt of je een nieuwe rollup introduceert.
- **Stream processor** leest Kafka één keer en schrijft naar beide sinks — append raw naar de lake, upsert rollups voor rapporten.

```js
// Eén consumer leest Kafka één keer en schrijft naar BEIDE 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) },// aggregeer -> OLAP (rapporten)
               { 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)
```

Ouders raken **voor-geaggregeerde samenvattingen** aan, dus een rapport is een key lookup, nooit een scan over miljarden rijen. ML bevraagt de **raw lake** en behoudt elk veld voor feature engineering.

## Stack & waarom
- **Kafka** — buffer, ontkoppelen, replay.
- **ClickHouse / dagelijkse samenvattingstabellen** — read-optimized voor ouderdashboards.
- **S3 + Parquet** — goedkope, columnar, flexibele raw storage voor ML.
- **Schema registry** — dwing het event-contract af zodat producers consumers niet stilletjes kunnen breken.

## Interview-lens
De interviewer peilt of je **write-optimized ingest scheidt van read-optimized serving**, of je voorkomt dat je raw events scant voor elk ouderrapport, en of je raw data behoudt voor ML. **Zwak:** "stop het allemaal in Postgres en query erop." **Sterk:** duurzame buffer + twee serving-paden + replay + een schema-contract, met gevoel voor de schaal.

## Trade-offs
Voor-aggregatie geeft directe reads maar legt de dimensies vooraf vast; de raw lake is flexibel maar traag. Houd **beide** — de klassieke write-once, read-many splitsing.

Write path (ingest)

Read path (serving)

Stack & waarom

Interview-lens

Trade-offs

Gerelateerde vragen