Prepare for a launch traffic spike
capacity planning for a known surge.
model expected load, load-test to find the first bottleneck, scale and cache, add graceful degradation and a queue for spiky writes.
turning up autoscaling without finding the bottleneck.
WHAT THIS TESTS The interviewer wants disciplined capacity planning, not hand-waving about the cloud scaling infinitely. A known launch spike is the easy case to prepare for, and they expect a measurement-driven process that finds the real bottleneck.
A GOOD ANSWER COVERS First model the load: translate 100,000 signups over 24 hours into a realistic peak requests-per-second, accounting for burst at announcement time and the heavier write path of signup versus read traffic. Then load-test against a production-like environment with realistic scenarios, ramping until something breaks, because the goal is to find the first bottleneck. It is usually not the stateless app tier, which scales horizontally, but the database, connection pool exhaustion, a third-party dependency like an email or payment provider with its own rate limits, or a shared cache. Remediate by adding read replicas or caching, increasing pool limits, pre-warming autoscaling so it does not lag the spike, and putting spiky writes like welcome emails behind a queue to smooth them. Build graceful degradation: shed non-essential features under load and keep the signup path alive. Finally, have observability dashboards and a runbook ready for launch day.
COMMON WRONG ANSWERS Saying turn on autoscaling and it is handled, ignoring that stateful tiers and external dependencies do not autoscale. Skipping load testing, so the bottleneck is discovered live. No fallback when the database or an email provider saturates.
LIKELY FOLLOW-UPS Why is the database usually the bottleneck before the app tier? Why pre-warm autoscaling? How would you queue and rate-limit the welcome-email path?
ONE CONCRETE EXAMPLE Load testing reveals the app tier scales fine but the database connection pool saturates at a fraction of target load. You add a connection pooler, move welcome emails to an async queue so they do not block signup, pre-warm autoscaling thirty minutes before the announcement, and add a degraded mode that disables analytics writes if load spikes. The launch absorbs the surge without manual firefighting.
Read the original → docs.cloud.google.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.