Posts

HTTP was designed for request response. The client asks. The server answers. The connection closes. If the client wants new data, it asks again. And again. And again. This works fine for loading a web page. It breaks down when you need real time updates. A chat application needs messages to appear instantly. A stock ticker needs price changes pushed the moment they happen. A collaborative document needs edits from one user to appear on another user’s screen within milliseconds. ...

You need to create a new record in your database. It needs an ID. In a single server world, this is trivial. An auto incrementing integer. 1, 2, 3, 4. The database guarantees uniqueness because there’s one sequence and one machine managing it. Now you have 50 servers writing to a sharded database. Server A inserts a row and gets ID 7. Meanwhile, Server B also inserts a row and also gets ID 7. Two different records, same ID. Collision. ...

You type “Lake Tahoe, 2 guests, next weekend” into Airbnb’s search bar. In under 500 milliseconds, the system filters millions of listings down to a few hundred that match your criteria, ranks them by relevance, applies dynamic pricing, checks availability calendars, loads review scores, and renders a page with photos, prices, and superhost badges. Every step must be fast. Every step must be personalized. Every step must handle the nuances of a two sided marketplace where supply changes daily and demand fluctuates by season, holiday, and local events. ...

Your payment service goes down. Your checkout page makes a synchronous call to the payment service. The call hangs. The thread pool fills up with waiting connections. No more threads available. The checkout service becomes unresponsive. Users can’t even browse products now. A failure in one service cascaded to bring down another. This is a cascading failure. And it’s the most dangerous type of failure in distributed systems because it turns a small problem into a system wide outage. ...

A user reports that the checkout page is slow. You open your monitoring dashboard. CPU is fine. Memory is fine. Request latency shows a bump. But which service caused it? The request passed through the API gateway, the auth service, the cart service, the pricing service, the inventory service, and the payment service. One of them is slow. Which one? In a monolith, you have one log. You search it. You find the slow function. Problem solved in minutes. ...

Most developers learn data modeling from textbooks. Normalize everything to third normal form. Eliminate redundancy. One fact in one place. Every column depends on the key, the whole key, and nothing but the key. Then they build a real system. Queries take 200ms because joining five tables for every page load is expensive at scale. The application spends more time assembling data from normalized tables than doing anything useful. The database CPU is pegged at 90% on joins alone. ...

Netflix serves over 250 million subscribers across 190 countries. It processes over a petabyte of data per day. It accounts for a significant percentage of global internet traffic. And its engineers deploy code thousands of times per day across hundreds of microservices with essentially zero downtime. This is not an accident. It is the result of deliberate architectural decisions designed around one principle above all others. Availability matters more than anything else. A user trying to watch a movie who sees an error will cancel their subscription. A worse movie recommendation is a minor annoyance. The system is built to stay up even when pieces of it fail. ...

Your application serves 100 users. One server handles it fine. Then it serves 1,000. Still fine. Then 10,000. The server’s CPU hits 90%. Response times creep up. Database connections start timing out. You need to do something. That something is scaling. But scaling is not one thing. It’s a set of decisions, each with tradeoffs. The first decision is the simplest. Do you make the existing machine bigger, or do you add more machines? ...

A user in Tokyo requests a web page hosted in Virginia. The request travels across the Pacific, through multiple routers, to the origin server. The server processes it. The response travels back. Total round trip? 300 milliseconds on a good day, 500 or more on a bad one. Every image, every script, every stylesheet makes the same journey. Now put a server in Tokyo that holds a copy of that static content. The user’s request travels to a local data center. The response comes back in 20 milliseconds. That’s the difference between a page that loads instantly and a page that feels broken. ...

Two servers try to withdraw money from the same bank account at the same time. Server A reads the balance as 1000. Server B also reads 1000. Server A subtracts 200 and writes 800. Server B subtracts 100 and writes 900. The final balance is 900. The account lost 200. This is a classic race condition. On a single machine, you fix this with a mutex. A lock. Only one thread can hold the lock at a time. The other waits. Problem solved. ...