Čas v aplikácii nie je iba výsledok now(). Riadi expiráciu, plánované úlohy, fakturáciu, retry, cache aj poradie eventov. Chyby sa často ukážu počas výpadku, DST alebo opakovaného doručenia. Spoľahlivý systém preto považuje hodiny za explicitnú závislosť a rozlišuje instant, calendar rule, duration a deadline. Skrytá globálna hodnota sa ťažko testuje a ešte ťažšie vysvetľuje pri incidente.

Význam vzniká pred dátovým typom

Stĺpec timestamp nehovorí, či ide o čas vytvorenia, používateľský termín alebo prijatie správy. Každý význam má inú politiku konverzie, aktualizácie a indexovania.

Názov a typ majú zámer zachytiť. Local date sa neskrýva v UTC polnoci a recurrence rule nie je iba prvý výskyt.

Clock má byť nahraditeľná závislosť

Priame volanie systémového času roztrúsené po kóde znemožní presné testy hraníc. Clock service v produkcii vráti real time, v teste fixný instant a kontrolovaný posun.

Tak možno overiť sekundu pred expiráciou, presnú rovnosť aj správanie po dlhom jobe bez čakania.

Duration používa monotónne hodiny

Latency, timeout a retry delay nemajú závisieť od wall clock, ktorý NTP posunie. Monotonic clock počas procesu neklesá a je vhodný na meranie intervalu.

Absolútny deadline medzi strojmi potrebuje toleranciu voči rozdielnym hodinám alebo prenos zostávajúcej duration s odpočítaním každého hopu.

Scheduler negarantuje presne jeden beh

Proces môže byť vypnutý, queue preťažená a lease môže vypršať tesne pred dokončením. Job preto potrebuje idempotentný side effect a stabilný occurrence ID.

Po obnove môže doména spustiť všetky zmeškané výskyty, iba posledný alebo žiadny. Fakturácia a marketingová pripomienka majú inú politiku.

Expirácia nie je cleanup

Token je po deadline neplatný, aj keď riadok zostáva v databáze. Rozhodovacia cesta musí čas kontrolovať pri použití. Cleanup job môže fyzické dáta odstrániť neskôr.

Hranica inclusive alebo exclusive musí byť presná. Rozdiel jednej milisekundy môže meniť bezpečnostný výsledok.

Event time a processing time nie sú rovnaké

Správa môže vzniknúť u producenta a prísť neskôr alebo mimo poradia. Timestamp od vzdialeného stroja nie je globálna sekvencia. Spotrebiteľ používa domain version, sequence alebo idempotency key.

Analytics potrebuje politiku late events a watermark: ako dlho spätne prepočítava výsledok a kedy dáta uzavrie.

TTL nie je presný alarm

Cache môže expirovanú položku fyzicky odstrániť neskôr. Ak platnosť ovplyvňuje bezpečnosť, aplikácia overí vlastný deadline. Jitter pri obnove zabráni tomu, aby tisíce položiek naraz vytvorili thundering herd.

Distributed lock s lease potrebuje fencing token. Starý pomalý vlastník môže pokračovať po tom, čo zámok získal nový proces.

Retry potrebuje backoff aj konečný stav

Exponential backoff s jitterom znižuje synchronizovaný nápor. Každý pokus však musí vedieť, či operácia už uspela. Platba alebo e-mail používa idempotentnú identitu a persistentný stav.

Po vyčerpaní pokusov sa job presunie do dead-letter workflow s dôvodom, nie do nekonečnej slučky.

Observability zachováva viac časov

Log môže uviesť scheduledAt, startedAt, finishedAt a eventAt. Dashboard potom rozlíši queue delay od processing duration. Jeden timestamp „time“ túto diagnostiku neumožní.

Trace používa korelačné ID a jednoznačné UTC instanty. Citlivý používateľský plán môže navyše zachovať timezone a lokálnu podobu.

Ručný zásah musí byť bezpečný

Operátor potrebuje znovu spustiť konkrétny occurrence, preskočiť chybný plán a zistiť, či side effect prebehol. Priamy update databázy obchádza audit a validáciu.

Admin nástroj používa rovnakú idempotency ochranu ako scheduler. Hromadný replay po výpadku sa dávkuje, aby nepreťažil závislosti.

Časové scenáre patria do testovacej matice

Testuje sa rovnosť s deadline, zmeškaný beh, duplicitné doručenie, DST, leap day, rozdielne poradie a výpadok počas side effectu. Integračný test používa produkčné databázové typy.

Spoľahlivý systém nepredstiera dokonale synchronný svet. Modeluje oneskorenie, opakovanie a neistotu. Ovládateľné hodiny a idempotentné operácie menia čas na testovateľnú súčasť architektúry.

Backlog mení význam plánovaného času

Ak queue spracuje job hodinu po scheduledAt, doména musí rozhodnúť, či je ešte užitočný. Denný report možno vytvoriť neskôr, no pripomienka päť minút pred schôdzkou už nedáva zmysel. Job má mať expiry alebo policy pre maximálne meškanie.

Dashboard sleduje rozdiel medzi scheduled, enqueued, started a finished. Rastúci queue delay sa tak odhalí skôr, než používatelia nahlásia oneskorené udalosti.

Distributed lease potrebuje fencing

Worker môže získať zámok na tridsať sekúnd, zastaviť sa počas GC a pokračovať po expirácii. Medzitým nový worker získa ďalší lease. Bez fencing tokenu môžu obaja zapísať výsledok a starý proces prepíše novší.

Každé získanie locku dostane rastúcu verziu, ktorú cieľové úložisko kontroluje. Samotné porovnanie aktuálneho času alebo predĺženie TTL neposkytuje rovnakú ochranu.

Business kalendár potrebuje explicitný zdroj

„Nasledujúci pracovný deň“ závisí od víkendov, štátnych sviatkov, regiónu a niekedy firmy. Nie je to obyčajné pridanie 24 hodín. Kalendár sviatkov má verziu, vlastníka a pravidlo aktualizácie.

Výpočet termínu môže uložiť použitú politiku, aby audit neskôr vysvetlil výsledok. Pri zmene sviatku sa rozhodne, či sa už potvrdené deadline prepočítajú alebo zostanú stabilné.

Nasadenie scheduler zmeny má shadow režim, ktorý porovná nové a staré next-run hodnoty bez spustenia side effectu. Rozdiely sa roztriedia podľa timezone, recurrence a business kalendára. Až potom sa nový výpočet stane autoritatívnym. Rollback musí zachovať occurrence IDs, aby sa rovnaká úloha po návrate nevykonala druhýkrát.

Prevádzkový dashboard sleduje rozdiely aj po nasadení.