તમે 10M timed tasks માટે scheduler કેવી રીતે ડિઝાઇન કરશો?

Question

IT Interview Practice · Accepted Answer

due time દ્વારા keyed **time-bucketed / priority queue** માં tasks સ્ટોર કરો, માત્ર *હમણાં* 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
```

## કમ્પોનન્ટ્સ અને flow

- **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 દ્વારા elected એક active poller છે; failure પર standbys take over કરે છે. પ્રતિ 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 બે વાર ચાલી શકે છે (poller dispatch પછી, done mark કરતાં પહેલાં crash થયો) — તેથી work પોતે idempotent હોવું જ જોઈએ, `task_id` પર keyed, નહીંતર તમે customer ને બે વાર charge કરો. Failures backoff સાથે retry થાય, પછી DLQ માં land થાય.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર બે વસ્તુ probe કરે છે: **efficient time lookup** અને **exactly-once vs at-least-once**. "Good" એ table પર cron loop છે; "great" એ sorted-set index વત્તા પ્રામાણિક કબૂલાત છે કે distributed exactly-once અવ્યવહારુ છે, તેથી તમે **at-least-once + idempotent workers** પસંદ કરો છો. એક classic trap: એક જ scheduler node પર ભરોસો કરવો — તે SPOF અને throughput છત છે. બીજું: ખૂબ સ્થૂળ (દર મિનિટે) poll કરવું જ્યારે tasks ને second precision જોઈએ, અથવા ખૂબ ઝીણું અને store ને hammer કરવું.

## Trade-offs અને failure

- **Precision vs load**: 1s tick second-level accuracy આપે છે પણ વધુ polls; scan cost ઘટાડવા tasks ને per-minute પછી per-second sub-queues માં bucket કરો (Kafka અને Quartz દ્વારા વપરાતો "timing wheel" / hashed-wheel approach).
- **At-least-once vs exactly-once**: તમે crash boundary પર true exactly-once મેળવી શકતા નથી; idempotency keys double execution ને હાનિરહિત બનાવે છે — સાચો trade.
- **Failure**: જો poller dispatch ના મધ્યમાં મરી જાય, leader election standby ને promote કરે છે અને un-acked tasks redeliver થાય છે — કંઈ ખોવાતું નથી, કેટલાક repeat થઈ શકે. nodes પર **clock skew** (NTP) ધ્યાનમાં રાખો નહીંતર tasks વહેલા/મોડા fire થાય; અને retries cap કરો જેથી કાયમ fail થતું task કાયમ loop ન કરે — inspection માટે તેને DLQ પર મોકલો.

આર્કિટેક્ચર

કમ્પોનન્ટ્સ અને flow

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો