Kepiye sampeyan nyimpen 100 yuta event log saben dina?

Question

IT Interview Practice · Accepted Answer

Bangun **pipeline append-only: agen → Kafka → panyimpenan berjenjang (panas ing ClickHouse/ELK, adhem ing object storage)** kanthi kebijakan retensi sing ngindeks data anyar lan ngarsipake sisane kanthi murah. 100 yuta event/dina yaiku ~1.200/detik rata-rata (lonjakan luwih dhuwur) lan puluhan-nganti-atusan GB saben dina — sampeyan ngoptimalake kanggo tulisan murah lan biaya query sing kaabatasi, dudu 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 iku write-once, ora tau diupdate — mula path ingesti yaiku **append**. Agen kaya **Fluent Bit / Vector** ngirim baris menyang **Kafka**, sing nge-buffer lonjakan lan misahake produser saka panyimpenan. Yen ClickHouse mati kanggo pangopènan, event antri ing Kafka lan replay — sampeyan ora ngeculake log. Batch tulisan (ewonan row saben insert) amarga insert saben-row ngrusak throughput ing columnar store.

## Hot store: indeks kanggo panelusuran

Log anyar butuh panelusuran cepet ("error ing jam pungkasan kanggo service X"). **ClickHouse** (columnar, ngompres 10x, nge-scan milyaran row/detik) utawa **ELK stack** (inverted index Elasticsearch) ngladeni iki. Partisi miturut dina/service supaya query nyunati dadi sawetara partisi. Tier iki larang saben GB, mula gawe cilik — mung 7–30 dina pungkasan.

## Cold store: object storage + tiering

Log sing luwih lawas pindhah menyang **S3 minangka Parquet** — murah, tahan lama, bisa di-query on demand liwat Athena/Trino. **Lifecycle policy** ngalih S3 → Glacier → pambusakan ing wates retensi sampeyan (contone 1 taun). *Tiering* iki minangka tuas biaya inti: panyimpenan panas bisa 50x regane arsip.

## Sudut pandang wawancara

Pewawancara nyoba **trade-off indeks-vs-biaya**: ngindeks kabeh menehi panelusuran apik nanging njeblug anggaran; ora ngindeks apa-apa iku murah nanging ora bisa di-query. Apik: "nganggo ELK." Apik banget: sampeyan berjenjang — indeks irisan panas anyar, arsip sisane kanthi adhem — lan nyebutake Kafka minangka buffer sing ndadekake ingesti tahan marang gangguan hilir.

**Jebakan umum:** nyelehake kabeh log ing Elasticsearch salawase. Iku pilihan sing paling larang lan cluster-e ambruk amarga kardinalitas/retensi sing ora sampeyan rancang.

## Trade-off lan mode kegagalan

- **Retensi vs biaya:** retensi luwih dawa = pertumbuhan panyimpenan linear; berjenjang kanthi agresif.
- **Backpressure Kafka:** yen consumer keri, disk kebak — ukur retensi lan monitor lag.
- **Ledakan kardinalitas:** kolom kardinalitas dhuwur (user_id) mbengkakake indeks ES; sampel utawa buwang.
- **Biaya query ing data adhem:** Athena nge-scan mbayar saben TB — partisi Parquet miturut tanggal/service supaya scan tetep kaabatasi.
- **Duplikat at-least-once:** dedup ing event id yen cacahan sing pas penting.

Pipeline append

Hot store: indeks kanggo panelusuran

Cold store: object storage + tiering

Sudut pandang wawancara

Trade-off lan mode kegagalan

Pitakon sing gegandhengan