System design scenarios

A small note-taking app needs the simplest real backend: one server and one database.

A small app gets a launch spike that one server cannot handle cleanly.

A read-heavy app asks the database the same questions again and again.

A catalog app has cache, but read volume still exceeds what the primary database should answer alone.

A write-heavy app tries to do every email and receipt while the user waits.

A media-heavy app wastes server capacity on files that belong at the edge.

A decent architecture still has to survive one production incident.

Simple project management tool. Steady traffic, modest scale. Your first real deployment.

Real-time messaging app launching publicly. Organic growth with unpredictable spikes from social shares.

E-commerce platform. You know the spike is coming. Budget is generous but the SLA is brutal.

A financial ledger app where the single database becomes the ceiling. Read replicas, connection pool tuning, and query offloading are the only paths forward.

An email delivery platform where sending, rendering, and delivery stats all compete for the same resources. Moving work off the request path is the only way to keep the API responsive.

A payments startup lands a partner launch. Checkout must stay fast while retries, auth, and DB reads compete for capacity.

A creator platform releases a video collaboration feature. Media delivery, asset storage, and app traffic all spike together.

Health monitoring platform. Lives depend on uptime. No excuses, no downtime, no exceptions.

A content recommendation feed where the ML ranking service becomes unstable. The feed must keep serving, even if recommendations are less personalized.

You inherit a live system that is already in trouble. Database overloaded, error rate climbing, latency spiking. Diagnose the bottleneck and stabilize before the SLA breach window closes.

A multiplayer backend goes live. Long-lived sessions, bursts of match events, and chat traffic punish shallow scaling.

An IoT telemetry platform gets a firmware rollout. Ingestion is cheap until streams, analytics, and storage all back up.

A mid-size SaaS is entering the evening peak. The previous engineer scaled servers repeatedly, but every read still lands on the primary database.

A fulfillment service moved writes behind a queue, but only one worker is draining it. The UI is still mostly green while backlog climbs.

A healthy internal tool is wildly overprovisioned. Finance needs a material cost cut before the next billing cycle without breaching the remaining peak.