Hur skulle du designa en scheduler för 10M tidsstyrda uppgifter?

Question

IT Interview Practice · Accepted Answer

Lagra uppgifter i en **tidsbucketad / prioritetskö** nycklad på förfallotid, polla bara de uppgifter som är förfallna *nu*, och lämna dem till idempotenta workers med **at-least-once**-leverans. Skanna aldrig 10M rader varje tick — indexera på avfyrningstid så att varje poll bara rör det som är förfallet.

## Arkitektur

```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
```

## Komponenter och flöde

- **Task store indexerad på avfyrningstid**: en Redis sorted set (`ZADD tasks score=due_ts`) eller en DB-tabell indexerad på `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` hämtar bara uppgifter förfallna denna sekund — O(log n), inte en table scan. **Sharding/partitionering** på task-id sprider 10M uppgifter över noder så att ingen enskild store blir het.
- **Poller med leader election**: varje partition har en aktiv poller vald via etcd/ZooKeeper; standbys tar över vid fel. En leader per partition undviker att två pollers dispatchar samma uppgift, medan partitionering håller throughput hög.
- **Ready queue (Kafka)**: förfallna uppgifter köas upp, vilket frikopplar *schemaläggning* från *exekvering*. Workers skalar oberoende av pollern.
- **Idempotenta workers** exekverar och **ackar**. Eftersom leverans är at-least-once kan en uppgift köras två gånger (poller kraschade efter dispatch, före markering som klar) — så själva arbetet måste vara idempotent, nycklat på `task_id`, annars debiterar du en kund dubbelt. Fel omförsöks med backoff och landar sedan i en DLQ.

## Intervjuperspektiv

Intervjuaren undersöker två saker: **effektiv tidsuppslagning** och **exactly-once vs at-least-once**. "Bra" är en cron-loop över en tabell; "utmärkt" är sorted-set-indexet plus det ärliga erkännandet att distribuerad exactly-once är opraktisk, så du väljer **at-least-once + idempotenta workers**. En klassisk fälla: att förlita sig på en enda scheduler-nod — den är en SPOF och ett throughput-tak. En annan: att polla för grovt (varje minut) när uppgifter behöver sekundprecision, eller för fint och hamra på storen.

## Avvägningar och fel

- **Precision vs last**: 1s tick ger sekundnoggrannhet men fler polls; bucketa uppgifter i per-minut och sedan per-sekund-underköer för att minska scan-kostnaden ("timing wheel" / hashed-wheel-ansatsen som Kafka och Quartz använder).
- **At-least-once vs exactly-once**: du kan inte få äkta exactly-once över en kraschgräns; idempotensnycklar gör dubbelexekvering ofarlig — den rätta avvägningen.
- **Fel**: om en poller dör mitt i dispatch befordrar leader election en standby och oackade uppgifter omlevereras — inget går förlorat, en del kan upprepas. Håll koll på **clock skew** över noder (NTP), annars avfyras uppgifter för tidigt/sent; och tak-begränsa omförsök så att en permanent felande uppgift inte loopar för evigt — skicka den till DLQ:n för inspektion.

Arkitektur

Komponenter och flöde

Intervjuperspektiv

Avvägningar och fel

Relaterade frågor