Distributed Job Scheduler  ·  View 12 of 20  ·  Runtime

Critical Flow — One Instant, Decided and Delivered

Eighteen messages, and the one that is the architecture: the ledger insert.

Editable source SVG draw.io All views
Time authority Partition owner Due index Fire ledger Lane queue Attempt runner Tenant target 1. now, with ε 2. [t-ε, t+ε] 3. ε > 100 ms? shed leases 4. scan due ≤ t-ε 5. instants + versions 6. apply overlap policy 7. insert fire (key) 8. committed 9. duplicate key: already decided 10. advance next_instant 11. enqueue on-time 12. lease task 13. mint token, sign record 14. POST fire + key 15. 202 accepted 16. timeout: state unknown 17. record attempt + state 18. outcome callback Critical Flow — One Instant, Decided and Delivered The ledger insert is the decision. Everything after it is retryable; nothing before it is dispatched. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • The owner asks the clock for an interval, not a timestamp, and scans for instants due at or before t−ε. It fires late by construction and never early (ADR-04).
  • A duplicate-key rejection on the ledger insert is a normal, expected return — it is how two owners mid-handover agree without talking to each other (ADR-03).
  • A dispatch timeout is recorded as unknown, not failed, because the target may have accepted it (ADR-12).

Assumptions

  • ε ≤ 10 ms, with a node shedding leases above 100 ms. Paying 10 ms of deliberate lateness on every fire is cheap; at 500 ms it would not be, which is what makes Question 3 in the ask a question about the achievable bound.
  • Residual duplicate dispatch ≤ 1 in 10^6 fires — assumed, and published as a contract rather than hidden behind an exactly-once claim.

Risks

  • A lease is a promise about time held by a node that may not know the time. Short leases need a trustworthy clock, and the clock is the thing being guarded against — the circularity is real and is bounded, not removed.