Hoe sla je 100 miljoen log-events per dag op?

Question

IT Interview Practice · Accepted Answer

Bouw een **append-only pipeline: agents → Kafka → tiered storage (hot in ClickHouse/ELK, cold in object storage)** met een retentiebeleid dat recente data indexeert en de rest goedkoop archiveert. 100M events/dag is gemiddeld ~1.200/sec (pieken veel hoger) en tientallen tot honderden GB per dag — je optimaliseert voor goedkope writes en begrensde querykosten, niet voor OLTP-semantiek.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: laatste 7–30d, geïndexeerd, snelle search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–jaren, goedkoop, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archief) ─▶ verwijder bij retentie
```

## Append-pipeline

Logs zijn write-once, nooit ge-updatet — dus het ingestie-pad is een **append**. Agents als **Fluent Bit / Vector** sturen regels naar **Kafka**, dat bursts buffert en producers van storage ontkoppelt. Als ClickHouse down is voor onderhoud, wachten events in Kafka en replayen — je dropt geen logs. Batch writes (duizenden rows per insert) omdat per-row inserts de throughput van columnar stores kapotmaken.

## Hot store: indexeren voor search

Recente logs hebben snelle search nodig ("errors in het laatste uur voor service X"). **ClickHouse** (columnar, comprimeert 10x, scant miljarden rows/sec) of de **ELK-stack** (Elasticsearch inverted index) bedienen dit. Partitioneer op dag/service zodat queries tot een paar partities snoeien. Deze tier is duur per GB, dus houd hem klein — alleen de laatste 7–30 dagen.

## Cold store: object storage + tiering

Oudere logs verhuizen naar **S3 als Parquet** — goedkoop, duurzaam, on-demand querybaar via Athena/Trino. Een **lifecycle policy** verplaatst S3 → Glacier → verwijdering bij je retentielimiet (bijv. 1 jaar). Deze *tiering* is de kernkostenhefboom: hot storage kan 50x de prijs van archivering zijn.

## Interviewperspectief

Interviewers peilen de **index-versus-kosten-afweging**: alles indexeren geeft geweldige search maar blaast het budget op; niets indexeren is goedkoop maar niet querybaar. Goed: "gebruik ELK." Uitstekend: je tiert — indexeer de recente hot slice, archiveer de rest cold — en benoemt Kafka als de buffer die ingestie bestand maakt tegen downstream-storingen.

**Veelvoorkomende valkuil:** alle logs voor altijd in Elasticsearch stoppen. Het is de duurste optie en zijn cluster valt om op cardinaliteit/retentie die je niet had gepland.

## Afwegingen & faalmodi

- **Retentie versus kosten:** langere retentie = lineaire opslaggroei; tier agressief.
- **Kafka backpressure:** als consumers achterlopen vult de schijf zich — dimensioneer retentie en monitor lag.
- **Cardinaliteits-explosie:** high-cardinality velden (user_id) blazen ES-indexen op; sample of drop ze.
- **Querykosten op cold data:** Athena-scans kosten per TB — partitioneer Parquet op datum/service zodat scans begrensd blijven.
- **At-least-once dupes:** dedup op een event-id als exacte tellingen ertoe doen.

Append-pipeline

Hot store: indexeren voor search

Cold store: object storage + tiering

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen