Know Your History: The Origin of HLD

No tool in this course was invented for fun. Load balancers, caches, queues and sharded databases each exist because something broke for real people at real scale, and an engineer had to invent a fix. High-Level Design (HLD) is the skill of choosing the big pieces of a system and deciding how they connect. Knowing the story behind each piece makes it far easier to remember when to use it, and to explain why in an interview.

Picture a bakery with one baker and one oven. At first it is perfect. Then the word spreads, the queue reaches the street, and the owner buys a bigger oven. That helps for a while, until no bigger oven exists, or none the owner can afford. So the owner opens a second shop, then a tenth, and a new set of questions appears. How do the shops share recipes and stock levels? What happens when one shop's oven breaks? How do customers find the nearest shop?

• -One baker and one oven is a single computer doing everything.
• -A bigger oven is vertical scaling: buying a more powerful machine.
• -More shops is horizontal scaling: spreading the work over many machines.
• -A broken oven is a server failure, which at large scale is normal rather than rare.
• -The shared recipe book and stock list is data that every machine must agree on, which is the problem of consistency.

Every era of system design below is one turn of this story: a fix that worked, then a new problem the fix created.

Say each user makes 10 requests a day. A site with 1 million users handles 10 million requests a day, which is about 116 per second on average. One ordinary server that can handle 500 requests per second copes easily. Now grow to 100 million users. That is 1 billion requests a day, about 11,574 per second on average, and the busiest hour might run five times higher, around 57,870 per second.

No one sells a machine 116 times faster than an ordinary one, and the price of power climbs steeply long before that. A single machine is also a single point of failure: when it stops, everything stops. So engineers started spreading work across many ordinary machines, and every era below is about the problems that created.

Early computers were room-sized mainframes that cost a fortune, so a whole company shared one. The machine sat idle while one person typed and everyone else waited. The fix was time-sharing: the computer switches between users so quickly that each feels they have it to themselves, like one kitchen serving many tables. This was an early multi-tenant system, meaning many separate users sharing one system without seeing each other's things.

A second problem arrived in the 1970s: programs broke whenever the physical layout of the data changed. Edgar F. Codd's relational model fixed that by describing data as simple tables and letting the database work out how to find it. When the one mainframe filled up, the only answer was to buy a bigger one.

When websites arrived, most were built from the same free ingredients, nicknamed LAMP: Linux (the operating system), Apache (the web server), MySQL (the database) and PHP or Perl (the code). Early pages used CGI, a way for the web server to run a small program for every request, starting it fresh each time. That was simple but slow. One server plus one database worked until a site got popular, and then the only fix was a bigger machine, which hit the limits you just saw.

Google had more data than any machine could hold, so it chose thousands of cheap machines and software that assumes some of them are always broken. GFS (the Google File System) stores huge files as copies spread across many machines. MapReduce splits a big job into many small pieces, runs them in parallel where the data lives, and combines the results. Bigtable is one giant table spread across many machines. Together they taught the industry its key lesson: build reliable systems out of unreliable parts.

Amazon's shopping cart cannot refuse your item just because a link between two data centers is down, because a lost sale costs money. Amazon's Dynamo paper described a store that always accepts writes, keeps copies on several machines, and lets the copies disagree briefly before they settle on the same answer. That is eventual consistency. Cassandra (from Facebook) and many key-value stores followed. A key-value store works like a giant dictionary: look up one key, get one value. NoSQL became the name for stores that trade some relational features for scale and availability.

A monolith is one big program deployed as a single unit: change a button color and you redeploy everything, and one bug can take everything down. Teams split monoliths into microservices, small programs that each own one job and talk over the network. That created new chores. Docker packages a program with everything it needs so it runs the same anywhere, like a shipping container. Kubernetes runs thousands of those containers across many machines. Service discovery lets programs find each other, because where a service runs keeps changing.

Apps now have users on every continent and data that never stops arriving. Kafka keeps a durable, ordered log of events that many systems can read independently, so one fact such as "a payment happened" can update search, analytics and notifications without those systems calling each other. Active-active multi-region means several regions serve users at the same time and each accepts writes, so a regional outage does not stop the service. Edge computing pushes code even closer to the user.

When an interviewer asks why you chose Cassandra over PostgreSQL, you are not reciting a feature list. You are citing a trade-off that engineers made when one database server stopped being enough, and that is a much stronger answer.

The Architecture Chronicles below tell these same stories in far more depth, with the original papers, the outages that prompted them and the people involved. Open any chapter that caught your interest. None of it is required to continue, but reading it makes every later chapter easier to place on the timeline.