તમે દરરોજ 100M log events કેવી રીતે સ્ટોર કરશો?

Question

IT Interview Practice · Accepted Answer

એક **append-only pipeline બનાવો: agents → Kafka → tiered storage (hot ClickHouse/ELK માં, cold object storage માં)** એવી retention policy સાથે જે તાજેતરના data ને index કરે અને બાકીનું સસ્તામાં archive કરે. 100M events/day એ સરેરાશ ~1,200/sec છે (spikes ઘણા વધારે) અને દરરોજ દસ-થી-સો GB — તમે OLTP semantics નહીં, પણ સસ્તા writes અને bounded query cost માટે optimize કરો છો.

```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
```

## Append pipeline

Logs write-once છે, ક્યારેય update થતા નથી — તેથી ingest path એ **append** છે. **Fluent Bit / Vector** જેવા agents lines ને **Kafka** પર ship કરે છે, જે bursts ને buffer કરે છે અને producers ને storage થી decouple કરે છે. જો ClickHouse maintenance માટે down હોય, events Kafka માં queue થાય અને replay થાય — તમે logs drop કરતા નથી. batch writes કરો (પ્રતિ insert હજારો rows) કારણ કે per-row inserts columnar stores પર throughput નાશ કરે છે.

## Hot store: search માટે index

તાજેતરના logs ને ઝડપી search જોઈએ ("service X માટે છેલ્લા કલાકમાં errors"). **ClickHouse** (columnar, 10x compress કરે છે, billions of rows/sec scan કરે છે) અથવા **ELK stack** (Elasticsearch inverted index) આ serve કરે છે. day/service દ્વારા partition કરો જેથી queries થોડા partitions સુધી prune થાય. આ tier પ્રતિ GB મોંઘું છે, તેથી તેને નાનું રાખો — માત્ર છેલ્લા 7–30 દિવસ.

## Cold store: object storage + tiering

જૂના logs **S3 પર Parquet તરીકે** move થાય છે — સસ્તું, durable, Athena/Trino દ્વારા on demand queryable. એક **lifecycle policy** તમારી retention limit પર S3 → Glacier → deletion transition કરે છે (દા.ત. 1 વર્ષ). આ *tiering* એ મુખ્ય cost lever છે: hot storage archival કરતાં 50x કિંમત હોઈ શકે.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર્સ **index-vs-cost trade-off** probe કરે છે: બધું index કરવાથી શ્રેષ્ઠ search મળે પણ budget ઉડાડે; કંઈ index ન કરવું સસ્તું પણ unqueryable. Good: "ELK વાપરો." Great: તમે tier કરો છો — તાજેતરના hot slice ને index કરો, બાકીનું cold archive કરો — અને Kafka ને buffer તરીકે નામ આપો છો જે ingestion ને downstream outages સામે resilient બનાવે છે.

**સામાન્ય trap:** બધા logs ને હંમેશ માટે Elasticsearch માં મૂકવા. તે સૌથી મોંઘો option છે અને તેનું cluster એવી cardinality/retention પર પડી ભાંગે છે જેની તમે plan ન કરી હોય.

## Trade-offs અને failure modes

- **Retention vs cost:** લાંબી retention = linear storage growth; આક્રમક રીતે tier કરો.
- **Kafka backpressure:** જો consumers lag કરે, disk ભરાય — retention size કરો અને lag monitor કરો.
- **Cardinality explosion:** high-cardinality fields (user_id) ES indexes ને ફૂલાવે છે; sample કરો અથવા drop કરો.
- **Cold data પર Query cost:** Athena scans પ્રતિ TB ખર્ચ છે — Parquet ને date/service દ્વારા partition કરો જેથી scans bounded રહે.
- **At-least-once dupes:** જો exact counts મહત્વના હોય તો event id પર dedup કરો.

Append pipeline

Hot store: search માટે index

Cold store: object storage + tiering

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

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