Miten suunnittelisit ajastimen 10M ajastetulle tehtävälle?

Question

IT Interview Practice · Accepted Answer

Tallenna tehtävät **aikaslottiin jaettuun / prioriteettijonoon** avaimena eräpäivä (due time), pollaa vain *juuri nyt* erääntyvät tehtävät ja anna ne idempotenteille workereille **at-least-once**-toimituksella. Älä koskaan skannaa 10M riviä joka tickillä — indeksoi laukaisuajan mukaan, jotta jokainen polli koskettaa vain sitä, mikä on erääntynyt.

## Arkkitehtuuri

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

## Komponentit ja tietovirta

- **Laukaisuajan mukaan indeksoitu task store**: Redisin lajiteltu joukko (`ZADD tasks score=due_ts`) tai DB-taulu indeksoituna `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` vetää vain tänä sekuntina erääntyvät tehtävät — O(log n), ei taulun skannaus. **Sharding/partitiointi** task-id:n mukaan levittää 10M tehtävää nodejen kesken, jottei yksikään store ole kuuma.
- **Poller leader electionilla**: jokaisella partitiolla on yksi aktiivinen poller, joka valitaan etcd/ZooKeeperin kautta; standbyt ottavat vallan vikatilanteessa. Yksi leader per partitio välttää kahden pollerin lähettämästä samaa tehtävää, kun taas partitiointi pitää throughputin korkeana.
- **Ready queue (Kafka)**: erääntyneet tehtävät lisätään jonoon, mikä irtikytkee *ajastamisen* *suorittamisesta*. Workerit skaalautuvat pollerista riippumatta.
- **Idempotentit workerit** suorittavat ja **ackkaavat**. Koska toimitus on at-least-once, tehtävä voi ajautua kahdesti (poller kaatui lähetyksen jälkeen ennen valmiiksi merkitsemistä) — joten itse työn on oltava idempotentti, avainnettuna `task_id`:hen, tai veloitat asiakasta kahdesti. Epäonnistumiset yritetään uudelleen backoffilla ja päätyvät sitten DLQ:hun.

## Haastattelunäkökulma

Haastattelija tutkii kahta asiaa: **tehokasta aikahakua** ja **exactly-once vs at-least-once**. "Hyvä" on cron-silmukka taulun yli; "loistava" on lajitellun joukon indeksi plus rehellinen myöntäminen, että hajautettu exactly-once on epäkäytännöllinen, joten valitset **at-least-once + idempotentit workerit**. Klassinen ansa: yhden ajastin-noden varaan nojaaminen — se on SPOF ja throughput-katto. Toinen: liian karkea pollaus (minuutin välein), kun tehtävät tarvitsevat sekuntitarkkuutta, tai liian tiheä ja storen hakkaaminen.

## Kompromissit ja virhetilanteet

- **Tarkkuus vs kuorma**: 1 s tick antaa sekuntitason tarkkuuden mutta enemmän polleja; slotita tehtävät per-minuutti- ja sitten per-sekunti-alijonoihin karsiaksesi skannauskustannusta ("timing wheel" / hashed-wheel-lähestymistapa, jota Kafka ja Quartz käyttävät).
- **At-least-once vs exactly-once**: et voi saada todellista exactly-oncea kaatumisrajan yli; idempotenssiavaimet tekevät kaksoissuorituksesta vaarattoman — oikea kompromissi.
- **Vikatilanne**: jos poller kaatuu kesken lähetyksen, leader election ylentää standbyn ja ackkaamattomat tehtävät toimitetaan uudelleen — mitään ei menetetä, osa voi toistua. Tarkkaile **kellon ryömintää (clock skew)** nodejen välillä (NTP), tai tehtävät laukeavat aikaisin/myöhään; ja rajaa uudelleenyritykset, jottei pysyvästi epäonnistuva tehtävä silmukoi ikuisesti — lähetä se DLQ:hun tarkastettavaksi.

Arkkitehtuuri

Komponentit ja tietovirta

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset