Inside the Control Plane
How is the cloud service organised, and what stops it turning into a ball of mud?
Two front doors — one for people, one for machines — into twelve bounded modules, with every piece of infrastructure behind a replaceable adapter.
Drag to pan, scroll to zoom, click an element to trace it.
Open full screenWhat to look for
- The scheduler tick arriving as an input to operations, not as a separate system.
- The "12 bounded contexts" tag — that number is the module count, not an aspiration.
- The boundary labelled "Infrastructure adapters — replaceable" and what sits inside it.
Read the full explanation
There are exactly two ways into the Control Plane. People arrive at the App API with a session cookie, and every request proves workspace membership and a named permission before anything happens. Machines arrive at the Contract API under /api/v1 with an agent credential, and every request proves which agent it is and which workspace it belongs to. The two never share a code path, a credential, or a notion of identity.
Behind both doors are twelve domain modules — workspaces, devices, accounts, media, posts, jobs and so on. Each owns its own data and exposes exactly two entry points: one for the server, one that is safe to send to a browser. A module may not reach into another module’s internals; the linter enforces it, and the build fails if server-only code leaks toward the client.
One module is deliberately different. Operations is the only place allowed to compose a write across several domains — turning a post into a job, releasing credentials, applying a job outcome. Concentrating cross-domain writes in one module is what keeps the other eleven simple enough to reason about alone.
Everything below the domain layer is marked replaceable, and that label is doing real work: DynamoDB, S3, Secrets Manager and Cognito are each reached through a thin adapter. Swapping any one of them is a contained change, not a rewrite.
Engineers, and anyone assessing how maintainable the codebase is.