An interviewer says - we run in one region and we are adding a second for a video platform at Twitch scale. Which networking decisions do you want settled before any code is written, and which can wait?

What the interviewer is testing

Whether you can separate decisions that are expensive to reverse from decisions that are merely important. A second region is where a decade of addressing, naming and failover assumptions become permanent, and the candidate who starts with load balancers has missed the question.

The clarifying questions that change the answer

• Why a second region? Latency for users, regulatory data residency, or disaster recovery. These produce three different designs: active-active with locality routing, hard data separation, or a mostly-idle standby.
• What is the recovery objective, in numbers? An RTO of 15 minutes and an RTO of 4 hours differ by whether capacity is pre-provisioned, which is most of the cost.
• Does any state have to be strongly consistent across regions? If yes, the design question is the write path, and everything else follows from it.
• Who are the users? For live video the answer is usually ingest locality and egress economics, not database replication.

Settle before any code

1. Addressing. Non-overlapping CIDRs per region, with headroom for the fourth region and for an acquisition. Re-addressing a live region later means touching hard-coded addresses, partner allowlists and certificates with IP SANs - months of work. Cheap now, expensive forever after.
2. The failover mechanism and its granularity. Anycast, DNS steering, or a global front door; and whether failover is per-region, per-cell or per-service. This decides what a regional failure even means, and DNS-based failover in particular will not deliver what its TTL suggests.
3. Where the authoritative write lives, and therefore whether the second region can accept writes. This is a data decision expressed as a network one, and reversing it is a re-architecture.
4. Private connectivity between regions, and specifically whether inter-region traffic may cross the public internet. Changing this later re-opens every compliance conversation.
5. Egress and inter-region cost model, roughly. Cross-region transfer typically lists at a few cents per GB in 2025 to 2026, so a chatty service placed across regions can cost more in transfer than in compute - and the placement is hard to change once teams depend on it.

Can wait

Load-balancer choice, mesh adoption, CDN provider, protocol upgrades such as HTTP/3, the exact autoscaling policy, and per-service failover runbooks. All are reversible in a sprint, and arguing them first is how the irreversible list gets decided by default.

Common weak answers

• "Active-active everywhere." Stated without the write-path consequence. Active-active for reads is routine; for writes it is a consistency design that has to be specified.
• "Replicate the database and point DNS at both." The two hardest problems named as if they were steps.
• "We will work out addressing later." The one item on the list with no later.

What a strong answer adds

The organisational layer: a second region doubles the surface every team operates, so the question "which team owns region-two capacity planning, and does the on-call rota follow the sun" belongs in the same design review. The strongest candidates also name what they will not make multi-region in version one - the control plane, the analytics estate, the admin tooling - because partial multi-region with a stated boundary ships, and complete multi-region does not.