Introduction Your API receives a request. You need to send a confirmation email, resize an image, call a third-party webhook, and update an analytics counter. You could do all of that synchronous...
Introduction Your application writes a row. PostgreSQL says “committed.” The server loses power one millisecond later. When it comes back, is your row there? The answer is yes — and the reason i...
Introduction Your application has one user. Concurrency is not a problem. That user reads data, writes data, nothing conflicts with anything. Then you have ten thousand users. Two of them update ...
Introduction Your single database server handled your first 100,000 users just fine. Then you hit a million. Queries slowed down. Disk filled up. You threw more RAM at it. It helped — for a while....
Why B+ Trees Exist Your database has 50 million rows. You query by user ID. Without an index, the database reads every row until it finds yours. That’s a full table scan. It gets slower with every...
Why Single-Database Transactions Don’t Scale A transaction in a single database is simple. You start a transaction, make changes, commit. Either everything commits or nothing does. The database ha...
Why Replication Exists Your database will crash. Not maybe. It will. Hard drives fail, memory corrupts, someone runs the wrong command, power goes out. When that happens, you need another copy of ...
Introduction Most developers understand SQL. Fewer understand what happens after the query planner finishes — how rows are physically laid out on disk, why certain writes cost more than others, wh...
Introduction At some point you ship something that works perfectly in staging. The code is clean. The tests pass. You deploy it and feel good about it. Six months later you’re debugging a product...
The Real Cost - What happens when you don’t have idempotency Every backend engineer has experienced this: a user clicks a button, the request times out, they panic and click it again. Now somethin...