The Backend Developer’s Guide to Databases
Why “Where” Matters
I'm a passionate backend dev
Up until now in this series, our data has been living "out of a suitcase."
We’ve seen it travel across the world via TCP, get wrapped in HTTP headers, and pass through the checkpoints of Authentication and Rate Limiting. But eventually, the data needs to go home. It needs a place to stay where it won’t disappear the moment the server reboots.
Welcome to the world of Databases.
When beginners think about databases, they usually focus on the "What" (SQL vs. NoSQL). But as a backend engineer, the first thing you need to think about is the "Where."
The Persistence Paradox
Before we look at how databases work, we have to address a fundamental conflict in backend design: The Persistence Paradox.
The Problem: In our article on Statelessness, we learned that a high-quality backend server should have the memory of a goldfish. If a server crashes or we deploy new code, that specific instance of our application should be replaceable without losing anything.
The Paradox: If our servers are designed to be forgetful, how does the user stay logged in? How does their bank balance stay accurate?
The Solution: We move the "Memory" out of the application and into a specialized piece of software designed for one thing: Persistence. * Your Application Code is the "Brain." It’s fast and active, but it clears its slate every time it restarts.
- Your Database is the "Archive." It lives outside your app, ensuring that every piece of data is exactly where you left it, regardless of what happens to your servers.
Why "Where" Matters: The Latency Ladder
In backend engineering, the "where" determines the "how fast." To visualize this, imagine the time it takes to access data using a scale where 1 CPU cycle equals 1 second:
CPU Cache/RAM (The Desk): This is data living inside your running code. At this scale, it's like reaching for a pen on your desk. It takes about 15 seconds.
Local SSD (The Filing Cabinet): This is data on the server’s hard drive. Now, you have to get up, walk to the filing cabinet, and find the right folder. This takes about 4 days.
The Database Server (The Library Across Town): In professional setups, your database is on a different machine. You have to leave the building, get in a car, and drive across town through traffic (the network). At our "1 second" scale, this takes over a year.
Thinking in Backend means realizing that every database query is a "trip across town or even continent." If your code makes 100 queries to fulfill one user request, your app isn't slow because of your logic—it's slow because you're spending a century waiting for the car to come back with the data.
The Database is a Separate Process
This is a mental shift for many. When you run your application, the database is not inside your app. It is a separate living, breathing entity with its own CPU, memory, and limits.
Because it's separate, we have to manage the "phone line" between the App and the DB. This is why we use Connection Pools. You can't open 1,000 separate connections for 1,000 users; your database would choke. You have to share a small number of open lines, managing access just like we did with Rate Limiting.
The Trade-off: Storage vs. Retrieval
Every database makes a fundamental choice: Make it easy to put data in, or easy to get data out. * Relational (SQL): Like a strict, organized spreadsheet. Hard to change the structure (Schema), but incredibly powerful at finding complex relationships.
- Document (NoSQL): Like a giant folder of JSON files. Easy to throw data in without a plan, but gets complicated when you need to "join" different types of data later.
As a backend developer, you aren't looking for the "best" database; you’re looking for the one whose constraints match your business needs.
Scaling Up: Data Is Not Just Stored, It’s Placed
When you write a simple query like SELECT * FROM users WHERE id = 42;, you aren't just asking for data. Under the hood, you are asking a series of Placement Questions:
Which machine should answer this?
Which physical disk contains this row?
Which copy (replica) is allowed to respond?
What happens if that machine is down?
These are not "coding" questions. They are system behavior questions. Whether your data is on a single node or distributed across the globe changes everything.
The Escape Hatch: Replication
Most systems start with one database on one machine. It’s simple and consistent. But what happens if that machine disappears?
To solve this, we use Replication. We copy data so it exists in multiple places—usually one Primary (for writes) and several Replicas (for reads).
The Trade-off: The moment you replicate, you trade simplicity for availability. If data exists in more than one place, it cannot be perfectly in sync all the time. You can hide this lag, but you cannot eliminate the physics of it.
Geography is a Backend Problem
Why do we care about "Regions" in AWS or Google Cloud? Because physics is undefeated.
If your database is in Virginia and your user is in London or Mumbai, every "read" has to cross an ocean. That 100ms delay isn't a database problem; it's a geography problem. Thinking in Backend means asking:
Can we move the data closer to the user?
Can we shard the data so European users' data lives in London or Indian users data in Mumbai?
Sharding: Deciding Ownership
While replication copies data everywhere, Sharding puts specific data in specific places.
Shard A owns users 1-1000.
Shard B owns users 1001-2000.
Choosing a "Shard Key" is like choosing a future. If you pick a bad one, you pay for it later with painful migrations and downtime. Sharding is the ultimate "Where" decision because it defines who owns the truth for a specific piece of data.
Summary
The Latency Ladder dictates performance.
The Database is a Neighbor, not a roommate (it's a separate process).
Replication and Sharding are just advanced "Where" decisions.
Once you see the database as a physical location rather than a magical black box, your architectural decisions will finally start to make sense.
What Comes Next
In the next one, we’ll go deeper into Indexing: Why Your Database is Slow (and How to Fix It). Not how to create them, but why they work, what they trade, and when they lie to you.
This article is part of the Thinking in Backend series, where we learn backend engineering by understanding how systems think, not just how queries run.
