Campaign

Your product is gaining users. DB queries are the bottleneck — 90% of reads are for the same 100 products. Time to introduce a cache.

Engineering tells you a single server maxes out at 500 RPS. You're at 400 now and trending up. Time to learn about load balancers.

You're onboarding a new enterprise customer. Traffic will ramp from 100 to 800 RPS over the next hour. Design for the peak, optimize for cost.

Black Friday. Traffic is steady at 150 RPS then spikes to 1,000 RPS for 5 minutes at peak. You have a $1/hr budget. Design for the chaos.

Your database is getting hammered during traffic spikes. Every spike causes connection exhaustion and cascading errors. A queue can absorb the burst and feed the database at a steady rate.

It's 2am. Your on-call phone rings. The primary app server just died. Traffic is piling up and users are seeing errors. You swore you'd add redundancy last quarter. Now it's too late — or is it?

Your image processing service handles 100 uploads per second, and each job takes ~2 seconds. Processing everything synchronously means users wait 2s for an ack — and your server explodes at any burst. Decouple the upload endpoint from the worker fleet.

Your checkout service calls a fraud detection API. At t=45s it gets slow — 5× latency. Without protection every checkout hangs, and users see timeouts. Add a circuit breaker.

Your e-commerce platform normally handles 300 RPS. A flash sale starts at t=20s — traffic surges to 2,400 RPS for 40 seconds, then drops back. Static provisioning for peak wastes money at baseline. Use a K8s Fleet to auto-scale.

Your primary database crashed at 3am. No standby. No replica. You spent 45 minutes restoring from backup while users saw errors. It's time to never let that happen again.

Your K8s fleet keeps falling behind on traffic spikes. The HPA target is too conservative and the replica cap is too low — the scaler runs out of headroom before traffic peaks.

Your checkout service calls a payment API. At t=45s the payment API gets slow — timeouts start piling up. Without a circuit breaker, every checkout hangs for 5 seconds waiting for a response that never comes fast enough.

AWS us-east-1a just went dark. Your entire fleet — servers, database — all live in 1a. Traffic is dead. Add capacity in a second AZ so one AZ going down is invisible to users.

Your product page calls a recommendation service. At t=30s the recommendation service crashes — permanently. Without protection, the product page hangs waiting for recs that never come. Non-critical features should fail silently.

Your API gateway retries every failed request 3×. At t=60s users start getting timeouts and their clients retry too. A hiccup that should last 10 seconds turns into a 30-second avalanche — the backend is drowning in retried requests.

Your social feed database is groaning. 5,000 reads per second, and your primary can't keep up. Every user-facing page is slow.

Your inventory service writes 3,000 items per second. Your SQL database is at 100% utilisation and dropping writes. Adding more connections just makes the contention worse.

Your metrics pipeline ingests 10,000 events per second. You need every event persisted durably — even if a consumer crashes mid-processing. Your database can't absorb writes at this rate directly.

Your reporting service runs complex aggregation queries that lock tables for seconds. Your write service shares the same database — and now checkout is timing out during every report.

You're building a distributed likes counter. Your primary database is in us-east-1 and a replica syncs to eu-west-1. A network partition severs the link between them for two minutes. The business question: do you keep accepting writes on both sides (availability), or stop writes on the replica until the partition heals (consistency)?

Your platform now serves users in both the US and Europe. EU users are experiencing 300ms+ latency because all your infrastructure is in us-east-1. Then at t=3min, a full region failure takes down your us-east deployment. You need global coverage, low latency everywhere, and survival when an entire region drops.

Your streaming platform just hit 20,000 RPS. 80% of that is static assets — videos, images, JS bundles — all hitting your origin servers directly. They're overwhelmed and bleeding money.

A single misconfigured deploy just took down three critical services simultaneously. The post-mortem identified every single point of failure. Now redesign the architecture so the same blast radius is impossible.

You're the architect of a real-time multiplayer game backend. 50,000 concurrent players. Sub-100ms latency globally. 99.99% uptime. $10/hr budget. No hints. No guided callouts. Everything you've learned across the previous 27 levels applies here. At t=90s a traffic surge doubles your load. At t=150s two app servers crash simultaneously. At t=210s your cache gets flushed cold. Survive all three.