Scenarios

A concert-ticket site usually runs fine on one beefy server. But the moment a popular tour goes on sale, traffic jumps to ten times normal for about an hour, then drops back. During those spikes the single server is completely swamped — even though it's already one of the biggest machines the cloud rents — and fans get error pages. The team needs to survive these short, huge bursts.

A web app recently grew from one server to several behind a load balancer. Now users complain that they log in fine, but a click or two later they're suddenly logged out and asked to sign in again. Digging in, the team finds each server stores who's logged in inside its own memory — and the load balancer freely sends a user's next request to a different server, one that has never heard of them.

A celebrity's public profile page gets opened millions of times an hour. Building that page runs the same heavy database query every single time — joining posts, follower counts, and badges — and it always produces the exact same result, because the profile barely changes. The servers are melting under the load, even though almost everyone is asking for the identical page.

An online store keeps its product catalog in one database. Shoppers browse constantly — millions of reads an hour to view products — but the catalog itself changes rarely (a few price or stock updates a day). That one database is buckling, and when you check, almost all of its work is answering READ requests. The data comfortably fits on one machine; it's the flood of readers that's the trouble.

A delivery app keeps every order in one giant `orders` table on one database server. After a few huge years that single table holds billions of rows — so many that it no longer fits on the machine's disk, and even simple lookups crawl because the data is just too big for one box to hold and scan. The team has already added every sensible index. The table itself is the thing that's too big for one machine.

A company runs its data on several machines in different cities. One day the network link between two of them breaks, so the machines can't talk to each other for a while — but users keep sending requests. The company runs two products on this setup: a BANK that shows account balances, and a SOCIAL FEED that shows friends' posts. The team has to decide how each product should behave while the machines are out of contact.

When a shopper hits 'Buy', the checkout server does everything in one go: it charges the card, then sends a confirmation email, then tells a warehouse service to update inventory. The email and inventory services are slow and sometimes overloaded, so the shopper's request sits there waiting on them — and during busy sales the whole checkout times out, even though the payment itself already succeeded.

A weather API serves thousands of apps, and normally everyone gets snappy replies. Then one developer's runaway script starts firing thousands of requests per second from a single account — far more than any normal app. The server is now so busy answering that one script that everybody else's requests slow to a crawl. Total traffic isn't really that high; it's just wildly lopsided toward one caller.

A small web server takes one request, finishes it completely, then takes the next. Most requests need to fetch something from a slow database and spend most of their time just WAITING for that answer. While one request sits waiting, the server does nothing else — it won't even start the next person's request. So during busy times, a quick request can be stuck behind someone else's slow one, and the whole site feels frozen.

A photo has a 'likes' number stored in one place in memory. Two helpers (threads) both get a like at the exact same instant. Each one reads the current count of 100, adds 1 in its own head, and writes 101 back. Two likes came in, but the count only went up by one — it shows 101 instead of 102. One like just disappeared, and it happens randomly, only when two likes land together.

A banking app moves money between accounts, locking each account while it touches it. Thread A is moving money from account 1 to account 2, so it locks account 1 and then reaches for account 2. At the same instant, Thread B is moving money from account 2 to account 1, so it locks account 2 and then reaches for account 1. Now A holds 1 and waits for 2; B holds 2 and waits for 1. Neither will ever let go. The app just hangs — no crash, no error, frozen forever.

A game creates a brand-new thread for every little thing — one per bullet, one per spark, one per falling leaf — and ends up with ten thousand threads on a 4-core CPU. Each thread has almost no work to do. Yet the game stutters badly, and the CPU sits near 100% busy. Strangely, when a level has FEWER objects (and so fewer threads), the same CPU runs the game smoothly.

A photo-editing program opens a giant image that, all together, would need 12 GB of memory. The laptop only has 8 GB of real RAM, with other apps already using some of it. You'd expect the program to refuse to open — but it opens fine and lets you edit, as long as you're working on one part of the image at a time. Only when you rapidly jump all over the whole image does everything slow to a crawl.

A shopping site has an `orders` table with 50 million rows. The support team constantly runs 'find the order with this tracking number', and each lookup takes 8 seconds. Watching the database, you see that to find one matching row it reads all 50 million rows, one by one, checking each tracking number. There's nothing wrong with the answer — it just looks at everything to find the few rows it needs.

An online shop stores each order as a row that includes the customer's full shipping address, copied right into the order. A loyal customer with 600 past orders moves house. The team updates her address, but the script only touches 580 of her order rows — 20 are missed. Now the same customer shows two different addresses depending on which order you look at, and nobody's sure which is current.

A payment app moves $50 from Anya to Ben in two steps: first subtract $50 from Anya's balance, then add $50 to Ben's. One night the server crashed right after step one finished but before step two ran. When it came back up, $50 was gone from Anya but never arrived at Ben. The money simply vanished, and the books no longer balance.

A store has 100 units of a hot item in stock. Two orders come in at the exact same instant. Each one reads 'stock = 100', subtracts the amount it sold, and writes the result back. Order A sold 30 and wrote 70; Order B sold 40 and wrote 60. Both read 100 before either had written, so the final stock shows 60 — as if Order A's sale never happened. One of the two updates was silently lost.

In a banking system, transaction T1 locks Account A and then tries to lock Account B. At the same moment, transaction T2 has already locked Account B and now tries to lock Account A. T1 won't let go of A until it gets B; T2 won't let go of B until it gets A. Neither can move, and both sit frozen — waiting on each other with no end in sight.

A team must store activity logs from millions of devices. The logs pour in by the billions per day, every device sends a slightly different set of fields, and the shape keeps changing as new device types ship. They're trying to force these into a strict table with fixed columns, and every new field means a painful schema change while the write rate keeps outgrowing one machine. (Their banking app, with strict accounts and transfers, is a totally different story.)

You're building a live video-call app. The picture keeps freezing for a second, then jumps ahead. Looking closer, you see that whenever one tiny packet of video gets lost on the way, the connection stops and waits — re-sending that one lost packet and holding back everything after it until the missing piece arrives. By the time the old packet finally shows up, that moment of the call is long gone, but everyone already saw the freeze.

You just set up a new web server. When you type its raw address — a string of numbers like 203.0.113.7 — straight into the browser, the site loads perfectly. But when you or a friend types the friendly name you bought, 'mycoolsite.com', the browser says it can't find the site. The server is up, healthy, and serving pages fine — it just won't answer to its name.

Your login page lives at an address starting with 'http://'. A learner sits in a coffee shop, opens a free tool that watches the shared wifi, and logs into your site. To their shock, they see their own username and password appear in the tool as plain readable text, right as it leaves their laptop. The data is correct and the login works — but every word of it travels across the network in the open, where anyone nearby can copy it.

Your website's one server sits in a data center in New York. Visitors in New York say the site loads instantly. But users in Australia complain that images and videos take forever to appear — even though the server isn't busy and has plenty of spare power. Every picture they request has to travel all the way across the planet and back, one file at a time.

You run a small game server on your laptop at home. Everyone on your home wifi can join it instantly. But when a friend across town tries to connect from the internet — using your home's public address — their connection just hangs and times out. Your laptop is on, the server is running, and you've even found your home's public address. From the outside, though, it's as if the server isn't there at all.