Distributed Job Scheduler  ·  View 02 of 20  ·  Context and scope

High-Level Architecture

The fire path as a spine: declare, remember, decide, commit, shape, deliver, account.

Editable source SVG draw.io All views
Declare Management API Cloud Run Validator next 3 instants Remember Trigger registry Spanner Due index time-ordered Decide Partition owner lease held Clock gate waits out ε Commit Fire ledger append-only, keyed Shape Dispatch lanes Cloud Tasks Jitter smear peak second Deliver Dispatcher signs + mints Tenant target Account Fire history Bigtable 90 d Lateness facts BigQuery commit first state changes Distributed Job Scheduler — High-Level Architecture Interface / broker Application we own Data store Decision point Queue / topic External / third party synchronous event / async The spine is the fire path. Nothing is dispatched that is not already committed to the ledger. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • Commit precedes dispatch at every point on the spine. A dispatcher that dies mid-attempt loses an attempt and never a fire (ADR-01).
  • Rate shaping sits between the ledger and the dispatcher, not inside it, so a backlog is queued state rather than a burst of retries (ADR-09).
  • Lateness facts land in a separate reporting store so a punctuality question never competes with the fire path for capacity.

Assumptions

  • A design peak of 45,000 fires per second for five seconds at the top of the hour, from an assumed 60% of fires landing in the first second of a minute.
  • Steady state 5,800 fires a second — so the peak is roughly 8× the mean minute and is a dispatch problem rather than a scheduling one.

Deliberate omissions

  • The identity and monitoring fan-out touches every stage and is drawn only in views 16 and 18.
  • The management read paths (dry-run, next-fires, history) are in view 08, not on the spine.