System design is the art of making decisions about how to build software that works — for millions of users, under real-world constraints, at scale.

Every piece of software is a system. Even the simplest web application makes choices about where to store data, how to handle concurrent users, and what happens when things go wrong. As the number of users grows, these choices become critical.

System design is the discipline of thinking about these choices before you start writing code. It's about understanding the trade-offs, constraints, and requirements that shape an architecture — and making deliberate decisions rather than accidental ones.

Scale changes everything. An approach that works perfectly for 100 users might completely fall apart at 100,000. A database query that takes 10 milliseconds with 1,000 rows might take 10 seconds with 10 million. A server that handles 50 requests per second might need to handle 50,000.

Thinking at scale means anticipating these inflection points and designing systems that can grow gracefully. It doesn't mean over-engineering everything from day one — that's a different kind of mistake. It means understanding what will break first and having a plan for when it does.

If there's one thing to internalize about system design, it's this: every decision is a trade-off. There is no perfect architecture, no universal best practice, no one-size-fits-all solution. Every choice you make optimizes for some things at the expense of others.

Want strong consistency? You'll pay for it with latency. Want low latency? You might have to accept eventual consistency. Want high availability? You'll need redundancy, which costs money. Want to save money? You might have to accept some downtime.

Most web-scale systems share a common set of building blocks. Learning these building blocks and understanding when to use each one is the foundation of system design.

Load Balancers

There's a methodology to system design that, once you internalize it, makes even the most daunting design problems tractable. It starts with understanding what you're building and ends with iterating on your design as constraints change.

1. Clarify requirements.

One of the most important mindsets in system design is assuming that everything will fail. Hard drives crash, networks drop packets, data centers lose power, and code has bugs. If your system assumes everything works perfectly, it is fragile. If it assumes things will break, it can be resilient.

Two identical environments. Switch the router.

Roll out to a small subset of users first.

Update servers one by one.

The ability to quickly revert a bad deploy is more important than the ability to deploy quickly.

A reverse proxy that sits between clients and microservices.

Creating specific gateways for different client types (Mobile vs Web).

Let's break down a couple of key terms before we begin:

As opposed to Memcached, Redis supports a variety of data types. Each of them has it's own use cases and several serve to extend the functionality of Redis beyond a simple key-value store.\nYou can consider Redis to be something like a dictionary, where the keys are strings but the values can be of different types.\nDifferent keys will store different values and the type of value can be different for each key.

cache

cache hit