TL;DR: Peak per region is 50k QPS, which at 10ms of CPU each needs about 500 vCPU, or roughly 53 sixteen-core VMs at a 60 percent utilisation ceiling. Lose a region and survivors run near 88 percent at peak, increasing queueing risk: bound queues by the client timeout and shed low-priority traffic rather than discovering your limits during the failover.
How to approach it
Write down every input and derive everything else; unstated assumptions should be stated and marked. The interviewer will perturb one number (double the traffic, lose two regions) to check you did arithmetic rather than recitation. Draw architecture only after capacity exists on paper.
A strong answer
Baseline per region. Global traffic splits three ways: about 33k QPS nominal, and applying a 1.5x peak factor gives 50k QPS peak per region. Assume the given 10ms means CPU time rather than elapsed time; each request consumes 10ms of one core, so steady demand is:
50,000 req/s x 0.010s = 500 cores of CPU demand (assuming 10ms CPU service time per request)
Queueing delay grows as variable demand approaches service capacity. Use 60 percent as an initial utilisation target and validate it against measured service-time distributions and tail latency:
500 / 0.60 ≈ 834 vCPU → ceil(834 / 16) = 53 VMs per region (~848 raw cores)
Failover arithmetic, the part that actually gets scored. A region partitions and its traffic redistributes across the surviving two: each survivor takes half the lost region's peak share, so 50k plus 25k, call it 75k QPS peak per survivor. Required cores: 75,000 × 0.01 = 750. Available: 848. Utilisation lands near 88 percent. Queueing models predict rising delay near saturation, but the actual p99 depends on burstiness, scheduling and service-time variance; test this failover load. Three honest responses exist, and picking between them is the senior move.
Pre-provision N+1 regions' worth of headroom permanently, which converts failover pain into always-on cost of 79 VMs per region: ceil(750 / 0.60 / 16), versus 53 baseline, about 49 percent more fleet. Or accept degraded tails for the minutes of failover while shedding load to keep core traffic fast. Or pre-warm elastic capacity, which fails exactly when cloud capacity in the surviving region is also tight. I would run two-plus-headroom in normal operation with shedding as the pressure valve, and reverse that only if login availability is contractually guaranteed.
Queue depth from the timeout boundary. Clients give up at, say, 200ms. A queue only helps while it can drain within that budget, so its useful depth follows from Little's law: at roughly 75,000 / 53 ≈ 1,400 req/s arriving per VM under failover peak, a 200ms tolerance corresponds to about 280 requests in flight per VM (1,400 × 0.2). That 280 is mean total in-flight work at 200ms, not a safe queue capacity. Subtract service and downstream time from the deadline, measure burst/recovery behavior and cap waiting work with deadline-aware admission. Payload-only memory for 250 requests is about 500KB, excluding request objects, buffers and runtime overhead. Verify tails under load rather than promising every queued request meets its deadline.
Shedding by priority class. Classify at the edge: Tier 0 is interactive login and session validation; Tier 1 is analytics callbacks, profile enrichment, log shipping. When queue depth crosses its bound or CPU passes the ceiling, ingress proxies reject Tier 1 immediately with 429 and Retry-After, reserving capacity for interactive traffic. If high-priority demand alone exceeds capacity, it also needs bounded admission; shedding lower classes cannot guarantee flat latency. The classification must be configured before the incident and reviewed like code, because priorities invented mid-outage protect nothing.
State shapes the rest. Session validation is read-mostly and should verify locally per region against replicated token stores or stateless signed tokens, so reads survive partition without cross-region hops. Login and token rotation are writes into a durable store with quorum semantics; those are rare relative to validation and can tolerate regional degradation. This split is why "auth service" fails over gracefully while feeling like one system.
What interviewers probe next
"Your 10ms assumption doubles under failover stress. Now what?" Redo it honestly: 750 becomes 1500 vCPU required against 848 available, so shedding engages earlier and Tier 1 is effectively offline until capacity lands. Saying the new number beats defending the old one.
"Why not autoscale instead of pre-provisioning?" Boot-and-warm takes minutes and failover spikes arrive in seconds; autoscaling handles diurnal curves, not regional loss. Both, with different triggers.
"Where does the arithmetic go wrong in practice?" Forgetting the peak factor, doing global math once and never dividing by regions, and targeting 100 percent utilisation because the average graph looks comfortable.
Common mistakes
Drawing OAuth flows and token diagrams for twenty minutes. The round is capacity engineering; the auth design earns maybe two of the forty-five minutes.
Announcing numbers with no derivation. Every figure must trace back to the given inputs within one line of arithmetic.
Treating failover as free. The interesting content of this entire question is the gap between 60 percent steady-state and 88 percent failover utilisation.