6 posts tagged with "architecture"

Every previous post in this series has been quietly leading here. The moment you spread a system across more than one machine — replicas, shards, multiple services — you're doing distributed systems, and distributed systems have their own laws of physics. This final part is about those laws: why the network will betray you, what the CAP theorem really forces you to choose, and how message queues and microservices help you cope.

This wraps up my system design fundamentals series.

The database is where most systems live or die. You can scale stateless app servers all day by adding boxes, but the database holds state, and state is stubborn — it's the part that doesn't parallelize for free. So this post is about the two questions that matter most: which kind of database to pick, and what to do when one machine can't hold your data anymore.

This is part five of my system design fundamentals series.

If I could teach a junior engineer exactly one system design skill, it would be caching. Nothing else gives you as much speed for as little effort — a well-placed cache can turn a database that's melting under load into one that's barely warm. It's also the place people make the most subtle mistakes, because a cache is a second copy of your data, and two copies of anything eventually disagree.

This is part four of my system design fundamentals series. Let's make things fast, then talk about the ways caching quietly bites back.

We keep saying "just add more servers." This post is about the part nobody explains when they say that: how a request actually finds its way to one of those servers, and how the traffic gets spread so no single machine drowns. It's the plumbing of every scalable system, and understanding it removes a lot of hand-waving.

This is part three of my system design fundamentals series, following the posts on scaling and on estimation.

There's a moment in every system design discussion where someone has to answer "okay, but will it actually handle that?" — and the people who freeze are the ones who never learned to estimate. Back-of-the-envelope math has a reputation for being scary, but it's genuinely just multiplication with round numbers. This post covers how I do quick capacity estimates, plus the four-step framework I use to keep a design conversation from turning into a rambling mess.

This is part two of my system design fundamentals series. Part one covered scaling, latency, and availability, which you'll want in your head for the estimation part.

I've been meaning to write down how I actually think about system design for a while. Not the interview-flashcard version, but the mental models I reach for when someone asks "will this hold up when we have a million users?" So I'm turning it into a short series. This first post is about the foundations — scaling, latency, throughput, and availability — because almost every design decision downstream comes back to these four ideas.

If you've ever nodded along to "just add more servers" without being totally sure what that buys you, this one's for you.