Bagaimana Anda menyimpan 100 juta event log per hari?

Question

IT Interview Practice · Accepted Answer

Bangun **pipeline append-only: agent → Kafka → tiered storage (panas di ClickHouse/ELK, dingin di object storage)** dengan retention policy yang meng-index data terbaru dan mengarsipkan sisanya dengan murah. 100 juta event/hari adalah rata-rata ~1.200/detik (lonjakan jauh lebih tinggi) dan puluhan-hingga-ratusan GB harian — Anda mengoptimalkan untuk write murah dan biaya query terbatas, bukan semantik OLTP.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Pipeline append

Log ditulis-sekali, tidak pernah di-update — jadi jalur ingesti adalah **append**. Agent seperti **Fluent Bit / Vector** mengirim baris ke **Kafka**, yang mem-buffer burst dan memisahkan producer dari storage. Jika ClickHouse down untuk maintenance, event mengantre di Kafka dan replay — Anda tidak membuang log. Batch write (ribuan baris per insert) karena insert per-baris menghancurkan throughput pada columnar store.

## Hot store: index untuk pencarian

Log terbaru butuh pencarian cepat ("error dalam satu jam terakhir untuk service X"). **ClickHouse** (columnar, mengompres 10x, men-scan miliaran baris/detik) atau **ELK stack** (inverted index Elasticsearch) melayani ini. Partisi berdasarkan hari/service agar query memangkas ke beberapa partisi. Tier ini mahal per GB, jadi jaga tetap kecil — hanya 7–30 hari terakhir.

## Cold store: object storage + tiering

Log lebih tua pindah ke **S3 sebagai Parquet** — murah, durable, bisa di-query on demand via Athena/Trino. Sebuah **lifecycle policy** mentransisikan S3 → Glacier → penghapusan pada batas retention Anda (mis. 1 tahun). *Tiering* ini adalah tuas biaya inti: hot storage bisa 50x harga arsip.

## Perspektif wawancara

Pewawancara menyelidiki **trade-off index-vs-biaya**: meng-index semuanya memberi pencarian hebat tetapi menjebol anggaran; meng-index nothing itu murah tetapi tak bisa di-query. Baik: "gunakan ELK." Hebat: Anda melakukan tiering — index irisan panas terbaru, arsipkan sisanya dingin — dan menyebut Kafka sebagai buffer yang membuat ingesti tahan terhadap padamnya downstream.

**Jebakan umum:** menaruh semua log di Elasticsearch selamanya. Itu opsi termahal dan cluster-nya tumbang pada kardinalitas/retention yang tidak Anda rencanakan.

## Trade-off & mode kegagalan

- **Retention vs biaya:** retention lebih lama = pertumbuhan storage linear; lakukan tiering secara agresif.
- **Backpressure Kafka:** jika consumer lag, disk penuh — ukuran retention dan monitor lag.
- **Ledakan kardinalitas:** field berkardinalitas tinggi (user_id) menggembungkan index ES; sampel atau buang.
- **Biaya query pada data dingin:** scan Athena berbiaya per TB — partisi Parquet berdasarkan tanggal/service agar scan tetap terbatas.
- **Duplikat at-least-once:** dedup pada event id jika hitungan eksak penting.

Pipeline append

Hot store: index untuk pencarian

Cold store: object storage + tiering

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait