The brief and the constraints

A message arrives from the CTO on a Tuesday: "Atlas Field is global now. Design us a global architecture."

That sentence can't be answered. It isn't too hard; it's underspecified in a way that makes every answer equally defensible. A service mesh across three regions answers it. One Postgres in Frankfurt with a CDN in front answers it too. Both are correct replies to a question that doesn't constrain anything.

The first senior move is to go back and ask until the question has edges, before drawing anything.

What a constraint is

A constraint is a statement that makes at least one otherwise reasonable design illegal. "We want it fast" isn't a constraint, because it rules no design out. "Australian users must see a scheduled job list in under 400 ms at the 95th percentile" is one. It makes a single-region deployment in Frankfurt arithmetically impossible for some payload sizes and trivially possible for others. The arithmetic is the same arithmetic the senior course "Future: edge database" already made you do.

A constraint has a number, an owner and a consequence for being wrong. If you can't name all three, you have a preference, not a constraint.

The brief, after four days of asking

Atlas Field is a Rails application for scheduling field technicians. It started with one customer in São Paulo. It now has paying customers in Brazil, Germany and Australia. The engineering team is six people. One of them is on call at a time, and that person also ships features that week.

Here's what the asking produced.

Users and shape come first. There are about 40,000 daily active users. Peak is regional and staggered: each region's morning dispatch window is its own spike, and the three windows don't overlap. The workload is read-heavy, because technicians open the same schedule many times a day and change it rarely.

Next is the latency complaint. It came from Australia, and it was specific: "the schedule list takes about two seconds to appear." It didn't come from Germany, even though Germany is also a long way from São Paulo: about 9,800 km, against Australia's 13,350. Distance alone doesn't explain a gap that large, and lesson 2 spends its time on why.

Then there's the residency obligation. The German contract carries a clause: personal data of EU data subjects is stored and processed inside the EU. That's a contract term first and a GDPR matter second, which the senior course "Compliance: GDPR deep dive" covers. The difference matters, because a legal argument doesn't satisfy a contract term. A row sitting in a particular database does.

Then there's the money. Infrastructure spend must stay under US$4,000 a month, all-in, including backups and observability. The senior course "Operations: cost optimization" gave you the habit of pricing a design. Here the ceiling comes first, and the design has to live under it.

Last is the team: six engineers, one on call, and nobody who has run a multi-region database before. This is a constraint in the strict sense, because it makes designs illegal. A topology that requires someone to reason about split-brain at 3 a.m. isn't available to this team, however correct it is.

Why the team size is a real constraint and not an excuse

It's tempting to treat headcount as a soft input, something to route around with better tooling or more discipline. The senior course "Org design: team topologies" gives the sharper version. A team can only own what it can hold in its head during an incident, and a six-person team can hold only a few independent moving parts.

Operational surface is what you're spending. Every region, every replica, every queue backend and every proxy tier is a thing that can be the cause. The cost of a component isn't its monthly bill. It's the bill plus the time it adds to every future diagnosis.

A small surface, in this repository

The application you're reading this on sits at the low end of that spectrum. It's worth looking at before designing something larger, because it shows what the floor looks like.

It deploys with Kamal, with Postgres running next to the application. Its production configuration sets SOLID_QUEUE_IN_PUMA: "true", with the comment "No separate job container: run Solid Queue inside Puma." In config/environments/production.rb, the cache store is :solid_cache_store and the Active Job adapter is :solid_queue.

That's close to the whole operational surface: an application, a Postgres and one process model. None of it is a template for Atlas Field, which has obligations this application doesn't have. It's a reference point for what a component costs when you add one, and it's why the senior course "The Solid Stack strategy" exists.

How to work through this course

Every lesson advances the same design. There's no coding challenge in this capstone, for the same reason the junior course "Capstone: Task Tracker Pro" had none: a capstone is a project you build, not a puzzle you solve. The quizzes test whether a decision follows from a constraint, which is the only thing worth testing on a design course.

Before you read lesson 2, write your own answer to the brief, on one page. You'll disagree with parts of this course, and the disagreement is more useful if it's written down first.

The brief

Design the architecture for Atlas Field: a Rails scheduling application with 40,000 daily active users across Brazil, Germany and Australia, a read-heavy workload and regionally staggered peaks.

The constraints

1. Personal data of EU data subjects is stored and processed inside the EU. It's contractual, not advisory.
2. The schedule list renders in under 400 ms at p95 for every region.
3. Infrastructure spend stays under US$4,000 per month, all-in.
4. Six engineers, one on call, none with multi-region database experience.
5. Whatever you build, one person has to be able to explain its failure modes on a whiteboard in five minutes.

Hold all five at once. Lesson 2 starts where the physics does, with the one constraint you can't negotiate.