ਤੁਸੀਂ ਪ੍ਰਤੀ ਦਿਨ 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 ਨਾਲ ਜੋ ਹਾਲੀਆ data ਨੂੰ index ਕਰੇ ਅਤੇ ਬਾਕੀ ਨੂੰ ਸਸਤੇ ਵਿੱਚ archive ਕਰੇ। 100M events/ਦਿਨ ਔਸਤਨ ~1,200/sec (spikes ਬਹੁਤ ਵੱਧ) ਅਤੇ ਰੋਜ਼ਾਨਾ ਦਸਾਂ-ਤੋਂ-ਸੈਂਕੜੇ GB ਹੈ — ਤੁਸੀਂ ਸਸਤੇ writes ਅਤੇ bounded 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** ਵੱਲ ship ਕਰਦੇ ਹਨ, ਜੋ bursts ਨੂੰ buffer ਕਰਦਾ ਹੈ ਅਤੇ producers ਨੂੰ storage ਤੋਂ decouple ਕਰਦਾ ਹੈ। ਜੇ ClickHouse maintenance ਲਈ down ਹੈ, events Kafka ਵਿੱਚ queue ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ replay ਹੁੰਦੇ ਹਨ — ਤੁਸੀਂ logs drop ਨਹੀਂ ਕਰਦੇ। 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 per GB ਮਹਿੰਗਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ — ਸਿਰਫ਼ ਆਖਰੀ 7–30 ਦਿਨ।

## Cold store: object storage + tiering

ਪੁਰਾਣੇ logs **S3 ਵਿੱਚ Parquet ਵਜੋਂ** ਚਲੇ ਜਾਂਦੇ ਹਨ — ਸਸਤਾ, durable, Athena/Trino ਰਾਹੀਂ on demand queryable। ਇੱਕ **lifecycle policy** ਤੁਹਾਡੀ retention limit (ਜਿਵੇਂ 1 ਸਾਲ) ਉੱਤੇ 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 ਕਰੋ — ਅਤੇ Kafka ਦਾ ਨਾਂ ਓਸ buffer ਵਜੋਂ ਲੈਂਦੇ ਹੋ ਜੋ ingestion ਨੂੰ downstream outages ਪ੍ਰਤੀ resilient ਬਣਾਉਂਦਾ ਹੈ।

**ਆਮ ਫੰਦਾ:** ਸਾਰੇ logs ਸਦਾ ਲਈ Elasticsearch ਵਿੱਚ ਪਾਉਣਾ। ਇਹ ਸਭ ਤੋਂ ਮਹਿੰਗਾ option ਹੈ ਅਤੇ ਇਸਦਾ cluster ਓਸ cardinality/retention ਉੱਤੇ ਢਹਿ ਜਾਂਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **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 ਨੂੰ bloat ਕਰਦੇ ਹਨ; ਉਹਨਾਂ ਨੂੰ sample ਜਾਂ drop ਕਰੋ।
- **Query cost on cold data:** Athena scans per 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

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ