Si do ta projektonit një scheduler për 10M detyra me kohë?

Question

IT Interview Practice · Accepted Answer

Ruani detyrat në një **time-bucketed / priority queue** të indeksuar sipas kohës së skadimit, poll-oni vetëm detyrat e skaduara *tani*, dhe jepini ato te workers idempotentë me dorëzim **at-least-once**. Kurrë mos skanoni 10M rreshta çdo tik — indeksoni sipas kohës së ekzekutimit që çdo poll të prekë vetëm atë që është për t'u ekzekutuar.

## Arkitektura

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

## Komponentët dhe rrjedha

- **Task store i indeksuar sipas kohës së ekzekutimit**: një sorted set Redis (`ZADD tasks score=due_ts`) ose një tabelë DB e indeksuar në `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` tërheq vetëm detyrat e skaduara këtë sekondë — O(log n), jo një table scan. **Sharding/partitioning** sipas task-id shpërndan 10M detyra nëpër nodet që asnjë store i vetëm të mos jetë i nxehtë.
- **Poller me leader election**: çdo partition ka një poller aktiv të zgjedhur përmes etcd/ZooKeeper; standby-t marrin përsipër në dështim. Një leader për partition shmang që dy poller të dërgojnë të njëjtën detyrë, ndërsa partitioning e mban throughput-in të lartë.
- **Ready queue (Kafka)**: detyrat e skaduara vendosen në queue, duke bërë decouple të *scheduling* nga *execution*. Workers shkallëzohen pavarësisht nga poller-i.
- **Idempotent workers** ekzekutojnë dhe bëjnë **ack**. Meqë dorëzimi është at-least-once, një detyrë mund të ekzekutohet dy herë (poller-i u rrëzua pas dërgimit, para se ta shënonte të kryer) — kështu që vetë puna duhet të jetë idempotente, e indeksuar sipas `task_id`, ose i faturoni një klienti dy herë. Dështimet riprovojnë me backoff, pastaj bien në një DLQ.

## Këndvështrimi i intervistës

Intervistuesi heton dy gjëra: **kërkim efikas në kohë** dhe **exactly-once vs at-least-once**. "Mirë" është një cron loop mbi një tabelë; "e shkëlqyer" është indeksi sorted-set plus pranimi i ndershëm se exactly-once i distribuar është jopraktik, kështu që zgjidhni **at-least-once + idempotent workers**. Një kurth klasik: mbështetja në një node të vetëm scheduler — është një SPOF dhe një tavan throughput-i. Një tjetër: poll shumë i trashë (çdo minutë) kur detyrat kërkojnë saktësi në sekonda, ose shumë i imët duke goditur store-in pa mëshirë.

## Kompromiset dhe dështimi

- **Saktësia vs ngarkesa**: një tik 1s jep saktësi në nivel sekonde por më shumë poll-e; grupojini detyrat në sub-queue për çdo minutë pastaj për çdo sekondë për të prerë koston e skanimit (qasja "timing wheel" / hashed-wheel e përdorur nga Kafka dhe Quartz).
- **At-least-once vs exactly-once**: nuk mund të merrni exactly-once të vërtetë përtej një kufiri crash-i; idempotency keys e bëjnë ekzekutimin e dyfishtë të padëmshëm — kompromisi i duhur.
- **Dështimi**: nëse një poller vdes në mes të dërgimit, leader election promovon një standby dhe detyrat e pa-ack-uara ridërgohen — asgjë nuk humbet, disa mund të përsëriten. Kini kujdes për **clock skew** nëpër node (NTP) ose detyrat ekzekutohen herët/vonë; dhe kufizoni riprovimet që një detyrë përgjithmonë e dështueshme të mos bëjë loop pafundësisht — dërgojeni te DLQ për inspektim.

Arkitektura

Komponentët dhe rrjedha

Këndvështrimi i intervistës

Kompromiset dhe dështimi

Pyetje të ngjashme