Az idő egy alkalmazásban nem egyszerűen a now() eredménye. Lejáratot, ütemezett munkát, számlázást, retry-t, cache-t és eseménysorrendet irányít. A hibák rendszerint kiesés, DST vagy duplikált kézbesítés közben jelennek meg. A megbízható rendszer az órát explicit függőségként kezeli, és megkülönbözteti az instantot, naptári szabályt, durationt és deadline-t.

A jelentés megelőzi az adattípust

A timestamp oszlopnév nem mondja meg, létrehozási idő, felhasználói határidő vagy üzenetfogadás van-e benne. Mindegyik más konverziót és frissítést igényel.

A név és típus rögzítse a szándékot. A local date ne rejtőzzön UTC éjfélben, a recurrence ne csak első occurrence legyen.

Az óra cserélhető függőség

A szétszórt rendszeridő-hívás megnehezíti a határok tesztelését. Clock service produkcióban valódi időt, tesztben fix instantot és kontrollált előrelépést ad.

Így lejárat előtti, pontos egyenlőségi és utáni állapot várakozás nélkül ellenőrizhető.

A duration monotonic clockot használ

Latency és timeout ne függjön korrigálható faliórától. A monotonic clock a folyamat alatt nem csökken.

Gépek közötti deadline-nál clock skew vagy továbbadott hátralévő duration szabály szükséges.

A scheduler nem garantál pontosan egy futást

A process állhat, a queue torlódhat, a lease lejárhat közvetlenül befejezés előtt. A job stabil occurrence ID-t és idempotens side effectet igényel.

Visszaálláskor a domén dönt: minden kimaradt futás, csak az utolsó vagy egyik sem. Számlázás és marketingértesítés eltér.

A lejárat nem azonos a cleanuppal

A token deadline után érvénytelen akkor is, ha a rekord még adatbázisban van. A döntési út minden használatkor ellenőrzi az időt.

A cleanup tárhelyet és retentiont kezel. Az inclusive vagy exclusive határ pontosan dokumentálandó.

Az event time és processing time különbözik

Az üzenet késve vagy sorrenden kívül érkezhet. Távoli timestamp nem globális sequence. Consumer doménverziót vagy idempotency keyt használ.

Analytics meghatározza, meddig fogad late eventet és mikor tekinti lezártnak az eredményt.

A TTL nem precíz ébresztőóra

A cache fizikailag később törölhet. Biztonsági érvényességet az alkalmazás saját deadline-ja ellenőriz. Jitter megakadályozza az egyszerre lejáró elemek tömeges újratöltését.

Distributed locknál fencing token kell, hogy egy lejárt, lassú tulajdonos ne írja felül az újabbat.

A retry backoffot és végállapotot igényel

Exponential backoff jitterrel csökkenti a szinkronizált terhelést. Minden kísérletnek tudnia kell, sikerült-e már a művelet. Fizetés és e-mail idempotens identitást használ.

A kísérletek elfogyása után dead-letter workflow és kezelhető ok következik, nem végtelen ciklus.

Az observability több időpontot őriz

ScheduledAt, enqueuedAt, startedAt és finishedAt külön mező. A dashboard így queue delayt és processing durationt különít el.

Trace UTC instantot és correlation ID-t használ. A felhasználói tervhez timezone és local intent is megőrizhető.

A backlog megváltoztatja a job értékét

Egy órával későbbi riport még hasznos lehet, az öt perccel meeting előtt esedékes emlékeztető már nem. A jobnak maximum lateness vagy expiry policy kell.

A queue delay trendet még a felhasználói panaszok előtt figyelni kell. Recovery alatt a replay adagolva történjen.

A distributed lease fencinget igényel

Egy worker GC pause után a lease lejárta ellenére folytathatja a munkát, miközben másik már megszerezte. Mindkettő írhat.

Minden lock acquisition növekvő fencing tokent kap, amelyet a célrendszer ellenőriz. Pusztán a TTL meghosszabbítása nem ugyanaz.

A business calendar külön adatforrás

A „következő munkanap” hétvégétől, ünneptől, régiótól és céges szabálytól függ. Nem 24 óra hozzáadása.

Az ünnepnaptár verziózott és tulajdonosa van. Határidőszámítás megőrzi a használt policyt auditcélból.

A kézi beavatkozás legyen biztonságos

Az operátor újrafuttathat konkrét occurrence-t, kihagyhat hibás tervet és ellenőrizheti, történt-e side effect. Közvetlen adatbázis-update megkerüli az auditot.

Admineszköz ugyanazt az idempotency védelmet használja, mint a scheduler. Tömeges replay kontrollált batch-ekben fut.

A scheduler-változás shadow módban mérhető

Az új és régi next-run számítás side effect nélkül összevethető. A különbségek timezone, recurrence és naptár szerint elemezhetők.

Rollout után a monitoring tovább figyeli az eltérést. Rollback megtartja az occurrence ID-kat, hogy ne legyen dupla futás.

A prioritás nem helyettesíti a lejárati szabályt

Egy magas prioritású queue sem garantálja, hogy a munka a kívánt másodpercben elindul. Kapacitáshiány, dependency outage vagy regionális failover minden sort késleltethet. A job ezért ne csak prioritást, hanem legkorábbi futási időt, végső érvényességet és a késés esetén alkalmazandó üzleti döntést is hordozzon.

A worker induláskor újraértékeli ezt a szerződést. Lejárt promóciós üzenetet eldobhat, pénzügyi zárást viszont végrehajthat késve, jól látható riasztással. Az infrastruktúra így nem próbál minden doménhelyzetre egyetlen általános retry-szabályt ráerőltetni.

A jövőbeli események materializálása kompromisszum

Ha egy végtelen ismétlődő terv összes előfordulását előre létrehoznánk, rengeteg adat keletkezne és minden szabálymódosítás tömeges átírást igényelne. Ha viszont csak az utolsó pillanatban számolunk, egy scheduler-kiesés miatt nem lesz előkészített munka. Gyakori megoldás egy mozgó időablak, amely a következő heteket vagy hónapokat materializálja.

Az ablakot idempotens folyamat tölti, stabil occurrence azonosítókkal. Tzdata- vagy szabályfrissítéskor csak a még végre nem hajtott jövőbeli példányok számolhatók újra. A már lezárt események megőrzik azt a tervet és időpontot, amely alapján ténylegesen megtörténtek.

A kapacitástervezésnek is van idődimenziója

A scheduler átlagos terhelése félrevezető lehet, ha minden ügyfél egész órára vagy éjfélre időzíti a feladatát. A lokális éjfél ráadásul a zónák miatt hullámként halad végig a napon. A rendszernek az ilyen koncentrált csúcsokra, nem csupán napi összes munkamennyiségre kell méreteznie.

Determinált jitter szétterítheti azokat a műveleteket, amelyeknek nincs pontos felhasználói időígérete, például cache-frissítést vagy karbantartást. Számlázási és jogi határidőt viszont nem szabad láthatatlanul eltolni. A termékígéret dönti el, hol megengedett a terhelés simítása.

Az időteszt valódi széleket tartalmaz

Deadline egyenlőség, duplikált kézbesítés, kiesés side effect közben, DST, hónap vége és sorrendcsere mind teszteset. Az integráció produkciós adattípust használ.

A megbízható rendszer nem feltételez tökéletesen szinkron világot. Késést, ismétlést és bizonytalanságot explicit modellez, ezért az idő tesztelhető architekturális elem lesz.