రోజుకు 100M log events ను మీరు ఎలా store చేస్తారు?

Question

IT Interview Practice · Accepted Answer

ఒక **append-only pipeline: agents → Kafka → tiered storage (hot in ClickHouse/ELK, cold in object storage)** ను నిర్మించండి, ఇటీవలి data ను index చేసి మిగిలినది చవకగా archive చేసే retention policy తో. 100M events/day అంటే సగటున ~1,200/sec (spikes చాలా ఎక్కువ) మరియు రోజుకు tens-to-hundreds of 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 చేస్తుంది. maintenance కోసం ClickHouse down అయితే, events Kafka లో queue అయి replay అవుతాయి — మీరు logs ను drop చేయరు. batch writes (ఒక insert కి వేల rows) చేయండి ఎందుకంటే per-row inserts columnar stores పై throughput ను నాశనం చేస్తాయి.

## Hot store: search కోసం index చేయండి

ఇటీవలి logs కి fast search అవసరం ("service X కి గత గంటలో errors"). **ClickHouse** (columnar, 10x compress చేస్తుంది, సెకనుకు billions of rows scan చేస్తుంది) లేదా **ELK stack** (Elasticsearch inverted index) దీన్ని serve చేస్తాయి. queries కొన్ని partitions కి prune అయ్యేలా day/service ద్వారా partition చేయండి. ఈ tier ఒక్కో GB కి ఖరీదు, కాబట్టి దాన్ని చిన్నగా ఉంచండి — చివరి 7–30 రోజులు మాత్రమే.

## Cold store: object storage + tiering

పాత logs **S3 కి Parquet** గా తరలుతాయి — చవక, durable, Athena/Trino ద్వారా on demand queryable. ఒక **lifecycle policy** మీ retention limit వద్ద (ఉదా. 1 year) S3 → Glacier → deletion గా transition చేస్తుంది. ఈ *tiering* core cost lever: hot storage archival కంటే 50x ధర కావచ్చు.

## ఇంటర్వ్యూ దృక్కోణం

ఇంటర్వ్యూయర్‌లు **index-vs-cost trade-off** ను పరిశీలిస్తారు: అన్నింటినీ index చేయడం గొప్ప search ను ఇస్తుంది కానీ budget ను పేల్చుతుంది; ఏదీ index చేయకపోవడం చవక కానీ unqueryable. మంచిది: "ELK వాడండి." గొప్పది: మీరు tier చేస్తారు — ఇటీవలి hot slice ను index చేసి మిగిలినది cold గా archive చేస్తారు — మరియు downstream outages కి ingestion ను resilient చేసే buffer గా Kafka ను పేర్కొంటారు.

**సాధారణ ఉచ్చు:** అన్ని logs ను Elasticsearch లో శాశ్వతంగా ఉంచడం. ఇది అత్యంత ఖరీదైన option మరియు మీరు plan చేయని cardinality/retention పై దాని cluster కూలిపోతుంది.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

- **Retention vs cost:** ఎక్కువ retention = linear storage growth; aggressively 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 కి ఖర్చు — scans bounded గా ఉండేలా Parquet ను date/service ద్వారా partition చేయండి.
- **At-least-once dupes:** exact counts ముఖ్యమైతే ఒక event id పై dedup చేయండి.

Append pipeline

Hot store: search కోసం index చేయండి

Cold store: object storage + tiering

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు