दैनिक 10 करोड log event कसरी भण्डारण गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

एउटा **append-only pipeline बनाउनुहोस्: agent → Kafka → tiered storage (hot ClickHouse/ELK मा, cold object storage मा)** र एउटा retention policy सहित जसले भर्खरको data index गर्छ र बाँकीलाई सस्तोमा archive गर्छ। दैनिक 10 करोड event भनेको औसत ~1,200/sec (spike धेरै उच्च) र दैनिक दस-देखि-सयौं GB हो — तपाईं OLTP semantics होइन, सस्तो write र सीमित query लागतका लागि 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

log write-once हुन्छन्, कहिल्यै update हुँदैनन् — त्यसैले ingest path एउटा **append** हो। **Fluent Bit / Vector** जस्ता agent ले line लाई **Kafka** मा पठाउँछन्, जसले burst buffer गर्छ र producer लाई storage बाट decouple गर्छ। ClickHouse maintenance का लागि down भए, event Kafka मा queue हुन्छन् र replay हुन्छन् — तपाईं log गुमाउनुहुन्न। Batch write (प्रति insert हजारौं row) गर्नुहोस् किनकि प्रति-row insert ले columnar store मा throughput नष्ट गर्छ।

## Hot store: search का लागि index

भर्खरका log लाई छिटो search चाहिन्छ ("service X का लागि अन्तिम घण्टाका error")। **ClickHouse** (columnar, 10x compress गर्छ, प्रति-second अर्बौं row scan गर्छ) वा **ELK stack** (Elasticsearch inverted index) ले यो serve गर्छ। दिन/service अनुसार partition गर्नुहोस् ताकि query केही partition मा prune होस्। यो tier प्रति GB महँगो छ, त्यसैले सानो राख्नुहोस् — केवल अन्तिम 7–30 दिन।

## Cold store: object storage + tiering

पुराना log **S3 मा Parquet** को रूपमा सर्छन् — सस्तो, टिकाउ, Athena/Trino मार्फत माग अनुसार query गर्न सकिने। एउटा **lifecycle policy** ले तपाईंको retention सीमामा S3 → Glacier → deletion transition गर्छ (जस्तै 1 वर्ष)। यो *tiering* नै मुख्य लागत lever हो: hot storage archival भन्दा 50x महँगो हुन सक्छ।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारहरूले **index-बनाम-लागत ट्रेड-अफ** probe गर्छन्: सबै index गर्दा उत्कृष्ट search दिन्छ तर बजेट फुटाउँछ; केही index नगर्दा सस्तो तर query गर्न नमिल्ने हुन्छ। राम्रो: "ELK प्रयोग गर।" उत्कृष्ट: तपाईं tier गर्नुहुन्छ — भर्खरको hot slice index गर्नुहोस्, बाँकी cold archive गर्नुहोस् — र Kafka लाई downstream outage प्रति ingestion लाई लचिलो बनाउने buffer भनेर नाम दिनुहोस्।

**साधारण जाल:** सबै log सधैँ Elasticsearch मा राख्नु। यो सबैभन्दा महँगो विकल्प हो र यसको cluster तपाईंले योजना नगरेको cardinality/retention मा ढल्छ।

## ट्रेड-अफ र failure mode

- **Retention बनाम लागत:** लामो retention = रैखिक storage वृद्धि; आक्रामक रूपमा tier गर्नुहोस्।
- **Kafka backpressure:** consumer पछि परे, disk भरिन्छ — retention size गर्नुहोस् र lag monitor गर्नुहोस्।
- **Cardinality विस्फोट:** उच्च-cardinality field (user_id) ले ES index फुलाउँछन्; तिनलाई sample गर्नुहोस् वा drop गर्नुहोस्।
- **Cold data मा query लागत:** Athena scan प्रति TB खर्च हुन्छ — Parquet लाई date/service अनुसार partition गर्नुहोस् ताकि scan सीमित रहोस्।
- **At-least-once dupe:** exact count महत्त्वपूर्ण भए event id मा dedup गर्नुहोस्।

Append pipeline

Hot store: search का लागि index

Cold store: object storage + tiering

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू