आप प्रति दिन 10 करोड़ 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 करती है। 10 करोड़ events/दिन औसतन ~1,200/sec है (spikes उससे कहीं ऊंची) और रोज़ाना दसियों-से-सैकड़ों GB — आप cheap writes और सीमित query cost के लिए optimize करते हैं, OLTP semantics के लिए नहीं।

```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** पर भेजते हैं, जो bursts को buffer करती है और producers को storage से decouple करती है। अगर ClickHouse maintenance के लिए down है, events Kafka में queue होते और replay होते हैं — आप logs नहीं गिराते। writes को batch करें (प्रति insert हज़ारों rows) क्योंकि per-row inserts columnar stores पर throughput को नष्ट करते हैं।

## Hot store: search के लिए index

हाल के logs को तेज़ search चाहिए ("service X के लिए पिछले घंटे में errors")। **ClickHouse** (columnar, 10x compress करता है, अरबों 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 के ज़रिए मांग पर queryable। एक **lifecycle policy** आपकी retention limit (जैसे 1 वर्ष) पर S3 → Glacier → deletion transition करती है। यह *tiering* मुख्य cost lever है: hot storage archival की कीमत का 50x हो सकता है।

## इंटरव्यू का नज़रिया

Interviewers **index-बनाम-cost trade-off** परखते हैं: सब कुछ index करना बढ़िया search देता है पर बजट उड़ा देता है; कुछ भी index न करना सस्ता है पर unqueryable। अच्छा: "ELK इस्तेमाल करें।" बढ़िया: आप tier करते हैं — हाल के hot slice को index करें, बाकी को cold archive करें — और Kafka को उस buffer के रूप में नाम लेते हैं जो ingestion को downstream outages के प्रति लचीला बनाता है।

**आम जाल:** सभी logs हमेशा के लिए Elasticsearch में डालना। यह सबसे महंगा विकल्प है और इसका cluster उस cardinality/retention पर गिर जाता है जिसकी आपने योजना नहीं बनाई।

## ट्रेड-ऑफ़ और failure modes

- **Retention बनाम cost:** लंबी retention = linear storage growth; आक्रामक रूप से tier करें।
- **Kafka backpressure:** अगर consumers पीछे रहें, 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 सीमित रहें।
- **At-least-once dupes:** अगर exact counts मायने रखते हैं तो एक event id पर dedup करें।

Append pipeline

Hot store: search के लिए index

Cold store: object storage + tiering

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

संबंधित प्रश्न