When choosing the region for a new service's first deployment, which input removes candidates outright and which ones are traded?
answer
- two kinds of input, not one list
- one of them deletes candidates
- an obligation is not a preference
- distance, rate and availability are traded
- the preselected region is still a choice
basics
~20 sA residency obligation filters the candidate list before anything is compared: regions outside the required jurisdiction simply leave. Distance to users, the rate the region charges for the same service, and whether it offers what you need are then traded against each other.
solid answer
~40 sTreat the inputs as two groups. A **residency obligation** — a law, a regulator's rule or a contract clause saying this data stays inside a jurisdiction — is a filter: every region outside that jurisdiction leaves the list before any comparison begins, and no price or latency advantage buys it back. What survives is genuinely traded. Distance to users sets a round-trip floor they feel on every request. The same managed service is metered in the same unit everywhere but priced per region, so the rate can differ materially. And providers roll services, hardware generations and quotas out region by region, so a candidate may not offer what your design assumes. Practically: filter by obligation, shortlist by user distance, confirm the shortlist actually runs your architecture, then let price break the tie.
go deeper
Remember that the inputs are not all the same kind: one obligation can delete candidates outright, while distance, price and service availability are weighed. Say where the users are before saying anything about cost.
Explain why the obligation filters rather than scores, and why the same service is metered identically but priced per region. Give the order you would apply the inputs in and justify it.
Show that you check the shortlist actually runs your architecture and its starting quota before committing, and that you record the rationale — the next person inherits the choice without the context.
Frame it as a decision that is expensive to reverse and set the standard: which obligations are asked about at design time, who signs off, and how teams are stopped from accepting a preselected region by accident.
## Two kinds of input, and only one is a filter Picking the region a workload runs in looks like one comparison, and most of it is. One input is not part of the comparison at all. A **residency obligation** — a law, a regulator's rule, or a clause a customer wrote into a contract stating that this data stays inside this jurisdiction — does not compete with latency or price. It shortens the candidate list. Every region outside the jurisdiction leaves before the comparison starts, and no rate gap and no round-trip advantage buys one back in. Treating an obligation as a heavily weighted criterion is the classic first mistake: weights can be outvoted, and this cannot. Everything that survives the filter is then genuinely traded. - **Distance to users.** Physical separation sets a floor on round-trip time. Users feel it on every request, and no machine size or instance count changes it. - **The rate for the same service.** A managed service is metered in the same unit wherever the provider offers it, but the rate per unit is set per region. Local power, land, tax, network transit and hardware supply differ, so the same thing legitimately costs different amounts in different places. - **What the region actually offers.** Providers launch services, features, hardware generations and quota ceilings region by region rather than everywhere at once, so a candidate can simply not have the thing your design assumes — or not at the size you need on day one. - **Where the second region will go.** The first choice constrains the second: a recovery region has to be independent of the first, permitted by the same obligation, and able to run the same architecture. ## Why the order of the work matters 1. **Apply the obligation first.** It is the only input that can delete candidates, and applying it last means comparing regions you were never allowed to use. 2. **Shortlist by user distance.** Latency is the input with the most complaints attached and the least ability to be tuned later. Rank the surviving regions by where your users actually are — not where your team sits. 3. **Check the shortlist offers your architecture.** Confirm the services, hardware generation and starting quota exist there. A cheaper region you cannot deploy into is not cheaper. 4. **Let price break the tie.** Price the whole shape in each survivor against your own volumes, not one headline unit rate. ## What it costs to get each one wrong | Input | Kind | Cost of getting it wrong | Can you revisit it? | |---|---|---|---| | Residency obligation | Filter | A compliance problem, not a performance one; possibly a contract breach | No — it is imposed on you | | Distance to users | Trade | A permanent latency floor on every request | Only by moving the workload | | Regional rate for the same service | Trade | A recurring bill higher than it needed to be | Yes, but only by moving | | Service and quota availability | Trade | A design that cannot be deployed as written | Sometimes — providers add services over time | ## Why this is worth more than a default The region field is usually preselected, and a team under launch pressure accepts it. That preselection is a real decision made by nobody. Once the service runs, a store starts growing in that region, other systems attach to it, and the choice becomes expensive to reverse: the data has to move, everything attached has to cut over, and the bytes are charged on the way out. This is **data gravity** — the pull a large, well-connected store exerts on everything near it — and it is why an hour spent on the choice at design time is worth more than any amount of regret later. ## The shape of a defensible answer - Name the obligation first and say explicitly that it filters rather than scores. - Say who the users are and where, because that is what turns distance into a number. - Note that the rate for the same service is set per region and check it against your own volumes. - Confirm the region runs your architecture before you fall in love with its price. - State out loud that the decision is hard to undo, and record why you chose what you chose.
- Two surviving candidates both satisfy the obligation and are both near enough to the users. What breaks the tie?Check availability before price. Confirm both run the services, hardware generation and starting quota your architecture needs, since providers roll those out region by region. If both do, price each candidate against your own volumes rather than a headline unit rate, and prefer the one that leaves you a sensible independent region for recovery later.
- The obligation arrives after launch rather than before. What does that change?It turns a cheap decision into an expensive migration. The workload, the store, the backup copies and often the telemetry all have to end up inside the jurisdiction, and the data has to move while the service keeps running. This is why the obligation is worth asking about even when nobody has raised it yet.
- Does the same reasoning apply to a short-lived batch job with no stored data?The filter still applies if the job reads regulated data, but the trades weaken. With no users waiting on a round trip and nothing accumulating, a job is genuinely portable, so the regional rate and available capacity can dominate. The decision is cheap to reverse precisely because nothing has grown there.
saying these in an interview costs you the question
- Accepts whichever region the signup flow preselected
- Treats a residency obligation as one weighted criterion among many
- Picks on the cheapest rate, then meets the latency floor
- Assumes every region offers every service and quota
- Believes the region can be changed cheaply later
- Chooses the region nearest the engineering team, not the users