System Design

A database that is down gets fixed fast. A database that is merely slow quietly takes your whole system with it. Here is how that happens, and how to stop it.

A monolith doesn’t need to ask where its own functions live – they’re all compiled into the same process, at the same address, forever.

“Our database is struggling, so let’s add read replicas” and “Our database is struggling, so let’s shard it” get thrown around in design interviews and architecture reviews almost interchangeably – as if they were two flavors of the same fix. They aren’t.

If you are a DevOps engineer, there is a good chance that you already know more about system design than you think.
You have probably configured a load balancer at some point.

Adding a cache to a backend system is one of the most satisfying performance improvements an engineer can make. The change is often small – point your application at Redis,

Spend a few weeks studying System Design and you’ll start noticing a familiar cast of characters in every architecture diagram

Imagine you’re ordering a new phone online. You complete checkout, enter your payment details, and click Pay Now. The button spins for a few seconds. No confirmation appears. Thinking the payment didn’t go through, you click again.

Imagine you’re ordering a new phone online. You complete checkout, enter your payment details, and click Pay Now. The button spins for a few seconds. No confirmation appears. Thinking the payment didn’t go through, you click again.