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

System Context

What is inside the boundary, who touches it, and what the service refuses to own.

Editable source SVG draw.io All views
Platform dependencies Time authority Workload identity People Tenant developer Tenant on-call Platform SRE Security reviewer Where the work runs Tenant HTTP target Tenant queue Platform executor Workflow engine Scheduled Trigger Service decides when; never runs the work Where the evidence goes Monitoring Audit sink Billing declares asks "did it run?" owns punctuality audits privilege signed dispatch enqueue fire handle out of scope ε bound tokens signals privileged acts fire counts Distributed Job Scheduler — System Context Security / platform Person or role External / third party Queue / topic Data store synchronous event / async batch two-way In scope: deciding an instant is due and handing over a durable fire record. Out of scope: running the work, and orchestrating more than one step of it. Key management is omitted here and appears in views 10 and 18. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • The scheduler's output is a durable decision — a fire record — not a completed job. Execution is outside the boundary in all three target forms.
  • Workflow and DAG orchestration is explicitly out of scope and points at the separate distributed-workflow-orchestration-platform package.
  • The time authority is a dependency, not an assumption: the service asks for a bounded uncertainty interval and is prepared to be told the clock is untrustworthy.

Assumptions

  • 50,000 tenants, 20 million active triggers, 500 million fires a day — all assumed, not measured.
  • Executors can deduplicate on a key supplied with the fire. If they cannot, the at-least-once contract in view 12 is unsafe and ADR-03 has to change.

Risks

  • Tenants will read "dispatched" as "the work ran". The outcome split in view 12 exists to make that distinction visible, and it will still be misread.
  • Four outbound target forms means four different failure vocabularies arriving at one history view.
All views High-Level Architecture  ▶
Solution Architecture v1.0 · Google Cloud · Platform Architecture · 2026-10 · 20 views · 16 architecture decision records01-system-context