10M timed tasks కోసం ఒక scheduler ను మీరు ఎలా design చేస్తారు?

Question

IT Interview Practice · Accepted Answer

tasks ను due time ద్వారా keyed అయిన **time-bucketed / priority queue** లో store చేయండి, *ఇప్పుడు* due అయిన tasks ను మాత్రమే poll చేయండి, మరియు **at-least-once** delivery తో వాటిని idempotent workers కి అందించండి. ప్రతి tick కి 10M rows ను ఎప్పుడూ scan చేయవద్దు — fire time ద్వారా index చేయండి తద్వారా ప్రతి poll due అయినదాన్ని మాత్రమే తాకుతుంది.

## ఆర్కిటెక్చర్

```text
API ─▶ Task store (DB/Redis ZSET, score = due_ts)  ── 10M tasks, sharded
             │
     Poller (leader per partition) ── ZPOPMIN due<=now ──▶ Ready queue (Kafka)
             │ leader election (etcd/ZK)                       │
             ▼                                                 ▼
     other pollers idle/standby                       Worker pool (idempotent)
                                                        └─ ack ✔ / retry ✖ ─▶ DLQ
```

## కాంపోనెంట్‌లు మరియు ఫ్లో

- **fire time ద్వారా indexed అయిన Task store**: ఒక Redis sorted set (`ZADD tasks score=due_ts`) లేదా `(run_at)` పై indexed అయిన DB table. `ZPOPMIN`/`ZRANGEBYSCORE now` ఈ సెకనుకు due అయిన tasks ను మాత్రమే pull చేస్తుంది — O(log n), table scan కాదు. task-id ద్వారా **Sharding/partitioning** 10M tasks ను nodes అంతటా విస్తరిస్తుంది తద్వారా ఏ ఒక్క store hot కాదు.
- **leader election తో Poller**: ప్రతి partition కి etcd/ZooKeeper ద్వారా elect అయిన ఒక active poller ఉంటుంది; failure పై standbys అందుకుంటాయి. partition కి ఒక leader రెండు pollers ఒకే task ను dispatch చేయడాన్ని నివారిస్తుంది, అదే సమయంలో partitioning throughput ను ఎక్కువగా ఉంచుతుంది.
- **Ready queue (Kafka)**: due tasks enqueue అవుతాయి, *scheduling* ను *execution* నుండి decouple చేస్తాయి. Workers poller కి స్వతంత్రంగా scale అవుతాయి.
- **Idempotent workers** execute చేసి **ack** చేస్తాయి. delivery at-least-once కాబట్టి, ఒక task రెండుసార్లు నడవవచ్చు (dispatch తర్వాత, done గా mark చేయడానికి ముందు poller crash అయింది) — కాబట్టి పని దానిలో idempotent గా ఉండాలి, `task_id` పై keyed గా, లేకపోతే మీరు ఒక customer ను double-charge చేస్తారు. Failures backoff తో retry అవుతాయి, తర్వాత DLQ లో పడతాయి.

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

ఇంటర్వ్యూయర్ రెండు విషయాలను పరిశీలిస్తారు: **efficient time lookup** మరియు **exactly-once vs at-least-once**. "మంచిది" ఒక table పై cron loop; "గొప్పది" sorted-set index ప్లస్ distributed exactly-once అసాధ్యమనే నిజాయితీ అంగీకారం, కాబట్టి మీరు **at-least-once + idempotent workers** ను ఎంచుకుంటారు. Classic ఉచ్చు: ఒక్క scheduler node పై ఆధారపడటం — అది ఒక SPOF మరియు throughput ceiling. మరొకటి: tasks కి second precision అవసరమైనప్పుడు చాలా coarse గా (ప్రతి నిమిషం) poll చేయడం, లేదా చాలా fine గా చేసి store ను hammer చేయడం.

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

- **Precision vs load**: 1s tick second-level accuracy ను ఇస్తుంది కానీ ఎక్కువ polls; tasks ను per-minute తర్వాత per-second sub-queues లోకి bucket చేయండి తద్వారా scan cost తగ్గుతుంది (Kafka మరియు Quartz వాడే "timing wheel" / hashed-wheel approach).
- **At-least-once vs exactly-once**: crash boundary అంతటా నిజమైన exactly-once మీరు పొందలేరు; idempotency keys double execution ను హానికరం కాకుండా చేస్తాయి — సరైన trade.
- **Failure**: dispatch మధ్యలో poller చనిపోతే, leader election ఒక standby ను promote చేస్తుంది మరియు un-acked tasks redeliver అవుతాయి — ఏదీ కోల్పోదు, కొన్ని పునరావృతం కావచ్చు. nodes అంతటా **clock skew** ను (NTP) గమనించండి లేదా tasks ముందుగా/ఆలస్యంగా fire అవుతాయి; మరియు retries ను cap చేయండి తద్వారా శాశ్వతంగా fail అయ్యే task ఎప్పటికీ loop కాదు — దానిని inspection కోసం DLQ కి పంపండి.

ఆర్కిటెక్చర్

కాంపోనెంట్‌లు మరియు ఫ్లో

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

ట్రేడ్-ఆఫ్‌లు మరియు వైఫల్యం

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