Section 6: Nine Boxes, One Promise - High-Level Architecture

Executive Summary: This section assembles the components the previous five sections implied: a stateless API service, a consensus-replicated store, an etcd coordinator, sixteen scheduler nodes, per-tenant dispatch queues, tenant-owned workers, a Run-State service, a history archiver and an observability plane. For each we state what it owns, what we rejected and what would flip the choice, then trace the Payments team's daily-settlement-report from a timer row at 07:00Z to a SUCCEEDED run, and name what is missing on purpose.

The interviewer slides the marker across: "You've got your API and your tables. Now draw me the system." Resist drawing everything you know. A good architecture diagram is a map of ownership: every box answers what does this component own that nobody else owns? Two owners is a consistency bug. No owner is an outage waiting to be scheduled.

The Map

Read it as two loops whose only shared dependency is the store. The control loop is tenants telling us what should happen and when. The trigger loop is the system making it happen: nodes find due timers, turn them into runs, hand them to queues, and workers report back. That decoupling is why Section 2 could promise 99.9% for the API and 99.99% for the trigger path. If the API is down, nobody can create new schedules, but every promise already in the store still fires.

Quick check before moving on: