Capstone: global Rails
This capstone works through one design problem: a global architecture for Atlas Field, a Rails scheduling application with customers in Brazil, Germany and Australia. It starts by turning a vague request into five constraints on residency, latency, budget, team size and explainability. Round-trip arithmetic comes before any data moves, and per-region primaries with tenant-pinned writes follow. Later lessons cover Puma sizing, regional workers, compliance as a schema decision, components left out with revisit triggers, and per-region failure and restore planning.
What you'll learn
- ✓Turning a vague brief into constraints with a number, an owner and a consequence
- ✓Estimating latency from round trips and distance before changing topology
- ✓Choosing per-region primaries with tenant-pinned writes and a read replica
- ✓Sizing Puma processes and threads and running background jobs where the data lives
- ✓Treating data residency, deletion and AI risk as inputs to the schema
- ✓Planning failure modes, timed restores and per-region SLOs
The brief and the constraints
A message arrives from the CTO on a Tuesday: "Atlas Field is global now. Design us a global architecture."
Read the full lesson free →Curriculum
7 lessonsThe brief and the constraints
A vague CTO request becomes five constraints for Atlas Field: residency, latency, budget, team size and explainability.
Where the data lives, and what that costs
Round-trip arithmetic shows distance explains little of the delay, then per-region primaries with tenant-pinned writes are chosen.
What runs where: processes and operational surface
Sizing Puma from GVL behavior and memory, placing regional workers and Solid stack databases, and counting operational components.
Compliance as an architectural input
Residency as a schema decision: table inventory, per-region obligations, a deletion path and AI feature risk decided early.
What you deliberately do not build
Why Atlas Field skips a service mesh, sharding, event sourcing, GraphQL and multi-region writes, each with a revisit trigger.
Failure, blast radius, and recovery
Walking each component's failure mode: regional blast radius, replica lag, lock timeouts, timed restores and per-region SLOs.
Closing the series
A one-page summary of the design, the limits of models, and an exercise to apply to your own system.