Distributed Job Scheduler  ·  View 03 of 20  ·  People and journeys

Actors and Their Core Journeys

Six parties, their goals in their own voice, and what each of them gets to do.

Editable source SVG draw.io All views
Tenant engineering Tenant developer 4,200 across 50 k tenants Goal — I want a digest to go out every weekday at 09:00 in my customers' time zone, and I do not want to learn anything about distributed timers to get it. Core journeys Ship a scheduled job see view 04 Amend a schedule safely Dry-run before committing Tenant on-call pages at 07:40 Goal — Something did not land overnight. Tell me whether it fired, whether you decided not to, or whether my endpoint refused it — before I start reading my own logs. Core journeys The morning after an outage see view 05 Pause a misbehaving trigger Platform Platform SRE 6 on rotation Goal — I need one number that tells me the scheduler is not firing, because a scheduler that is up and silent looks perfectly healthy on every other dashboard. Core journeys Drain a zone without losing a fire Throttle a tenant's catch-up Rebuild the due index in shadow Product owner sets defaults Goal — I want the default behaviour after an outage to be the one that is least likely to bill a customer twice. Core journeys Set a tenant's quota Approve a backfill Assurance Security reviewer quarterly Goal — Show me that a schedule cannot be pointed at a host the tenant does not own, and that the person who can backfill is not simply anyone who can edit a trigger. Core journeys Trace a dispatch credential Audit a horizon extension Machines in the cast Tenant target HTTP, queue, executor Goal — Hand me a fire with a key I can deduplicate on, and do not assume my answer means the work finished. Core journeys Accept a signed dispatch Report an outcome Time authority ε ≤ 10 ms Goal — Tell the truth about how wrong I might be, and be believed rather than averaged. Core journeys Serve a bounded interval Who the Scheduler Is For, and What They Get to Do Person or role Journey / task External / third party Security / platform Goals are in each actor's own voice. The two journeys with their own view are the ones where the architecture is visible to the person living it. v 1.0 · owner Platform Architecture · date 2026-10

Why this view first

  • The developer's goal — "I do not want to learn anything about distributed timers" — is the constraint that forces the policy defaults in view 04 and ADR-06.
  • The tenant on-call's goal is the reason fire history is a product surface rather than a platform log: it has to answer a customer's question before anyone reads platform logs.
  • The time authority appears in the cast because being believed rather than averaged is a requirement it places on the design, not a property of a library.

Assumptions

  • 4,200 tenant developers and six platform SREs — assumed, and the ratio is the real figure: the platform cannot be the place where scheduling questions get answered by a human.

Risks

  • The product owner's goal ("least likely to bill a customer twice") and the developer's goal ("just make it fire") disagree about the missed-fire default. ADR-06 resolves it in the product owner's favour and some tenants will be surprised.
◀  High-Level Architecture All views Journey — Ship a Scheduled Job  ▶
Solution Architecture v1.0 · Google Cloud · Platform Architecture · 2026-10 · 20 views · 16 architecture decision records03-actors-and-journeys