آپ روزانہ 10 کروڑ log events کیسے store کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

ایک **append-only pipeline بنائیں: agents → Kafka → tiered storage (hot ClickHouse/ELK میں، cold object storage میں)** ایک retention policy کے ساتھ جو حالیہ ڈیٹا کو index کرے اور باقی کو سستے میں archive کرے۔ 10 کروڑ events/day اوسطاً تقریباً 1,200/sec (spikes کہیں زیادہ) اور روزانہ دسیوں سے سینکڑوں GB ہیں — آپ سستی writes اور محدود query لاگت کے لیے 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 کے لیے نیچے ہو، تو 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 تک محدود ہوں۔ یہ tier فی GB مہنگا ہے، لہٰذا اسے چھوٹا رکھیں — صرف آخری 7–30 دن۔

## Cold store: object storage + tiering

پرانے logs **S3 پر Parquet** کی صورت میں منتقل ہوتے ہیں — سستا، durable، Athena/Trino کے ذریعے demand پر queryable۔ ایک **lifecycle policy** آپ کی retention حد پر S3 → Glacier → deletion منتقل کرتی ہے (مثلاً 1 سال)۔ یہ *tiering* اصل لاگت کا lever ہے: hot storage archival سے 50 گنا مہنگا ہو سکتا ہے۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والے **index-vs-cost trade-off** جانچتے ہیں: سب کچھ index کرنا عمدہ search دیتا ہے مگر بجٹ اُڑا دیتا ہے؛ کچھ بھی index نہ کرنا سستا مگر ناقابلِ query ہے۔ اچھا: "ELK استعمال کرو۔" عمدہ: آپ tier کرتے ہیں — حالیہ hot slice کو index کریں، باقی کو cold archive کریں — اور Kafka کو اُس buffer کے طور پر نام دیتے ہیں جو ingestion کو downstream outages کے خلاف مضبوط بناتی ہے۔

**عام جال:** تمام logs ہمیشہ کے لیے Elasticsearch میں رکھنا۔ یہ سب سے مہنگا آپشن ہے اور اس کا cluster اُس cardinality/retention پر گر جاتا ہے جس کی آپ نے منصوبہ بندی نہیں کی۔

## توازن اور ناکامی کے طریقے

- **Retention بمقابلہ لاگت:** طویل retention = خطی storage نمو؛ جارحانہ انداز میں tier کریں۔
- **Kafka backpressure:** اگر consumers پیچھے رہیں تو disk بھر جاتی ہے — retention کا سائز طے کریں اور lag monitor کریں۔
- **Cardinality دھماکہ:** اعلیٰ cardinality fields (user_id) ES indexes پھلا دیتے ہیں؛ انہیں sample یا drop کریں۔
- **Cold data پر query لاگت:** 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

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات