In this chapter
We'll name the three real reasons GreenMart's data lives in multiple regions — latency, fault tolerance, and scale beyond one machine's limits — and meet vertical vs. horizontal scaling as the real choice underneath every one of them, with horizontal scaling's own honest cost: coordination.
The Problem in Real Life
Before any of this Act's incident makes sense, Sarah has to answer a more basic question Mike never actually asked out loud: why does GreenMart's data even live in three separate regions in the first place? Why not one very large, very well-maintained database, in one place, run properly?
The honest answer isn't one reason. It's three real, separate ones, and GreenMart hit all three, one at a time, across the exact Acts this course has already walked through.
We built this multi-region thing on purpose. Remind me why, exactly.
Mike
One Big Machine vs. Many Machines, Spread Out
Latency: distance costs real time
A customer far from the data pays for the round trip every time — a local copy is the only real fix.
Fault tolerance: one machine is one risk
Multiple real copies mean no single failure takes the whole system down.
Vertical scaling has a real ceiling
Even the largest real machine has a maximum size — horizontal scaling has no equivalent limit.
Horizontal scaling's honest cost: coordination
More machines means they now have to agree with each other — the real cost this whole Act exists to address.
Why Distribute Data & Scaling Up vs. Out
Why distribute data? has three real, distinct answers, and it's worth naming all three honestly rather than treating "distributed" as one single motivation:
- Latency. A customer in Singapore asking a database physically sitting in the US pays for the round trip, every single time, no matter how fast that US database itself responds. Keeping a real, local copy of the data close to where it's actually used is the only way to make that round trip genuinely short — this is exactly why GreenMart runs regional copies at all, the same real motivation Act 4's DynamoDB and Act 5's Cassandra Acts already built on.
- Fault tolerance. One machine, however well-maintained, is one real thing that can fail — a disk, a power supply, an entire data center losing power. Multiple real copies, in multiple real places, mean no single failure takes GreenMart fully offline. This is the same real motivation behind every replication factor this course has already taught (Cassandra's RF 3, DynamoDB's own replicas).
- Scale beyond one machine's real limits. Even the largest single real machine money can buy has a genuine ceiling — a maximum amount of RAM, a maximum disk throughput, a maximum number of simultaneous connections it can actually serve. Once a workload's real size or traffic exceeds that ceiling, no amount of "better hardware" fixes it; the only real answer left is more machines.
| Vertical Scaling (Bigger Machine) | Horizontal Scaling (More Machines) | |
|---|---|---|
| How it grows | Upgrade the one machine — more CPU, RAM, disk | Add more machines, split the work across them |
| Real ceiling | Yes — even the largest cloud instance has a maximum size | No fixed ceiling — keep adding machines |
| Real new cost it introduces | None beyond the hardware bill itself | Coordination — the machines now have to agree with each other |
| Simplicity | Simple — one machine, one place to look | Genuinely harder — this whole Act exists because of this row |
Every remaining chapter in this Act is really about that last row — the real coordination cost horizontal scaling introduces, which vertical scaling never has to pay because there's only ever one machine to begin with.
Vertical scaling — making one machine bigger — is genuinely the simpler path, and it's the right one for a real range of workloads that never actually outgrow a single well-provisioned machine. It fails specifically at the ceiling: once no single real machine is big enough, or once a single point of failure is no longer an acceptable risk, vertical scaling has nothing left to offer. Horizontal scaling — more machines, not a bigger one — has no equivalent ceiling, at the real cost this entire Act is about: machines that now have to coordinate, stay in sync, and agree with each other, instead of just being one thing a person can reason about alone.
GreenMart's three regions are horizontal scaling taken one deliberate step further: not just more machines, but more machines in genuinely different physical places, specifically for the latency reason named above. That extra step buys real, local speed for customers everywhere — and it's also exactly what turned an ordinary hardware failure into a real network partition, the kind chapter 1 already showed in concrete, painful detail.
Key Takeaway
GreenMart distributes its data for three real, separate reasons — latency, fault tolerance, and scale beyond one machine's limits — not because "distributed" sounds more advanced. Horizontal scaling buys all three, at a real, honest cost: machines that now have to coordinate with each other, which is precisely the cost this whole Act exists to teach GreenMart how to actually pay.
Why This Matters
Every remaining chapter in this Act is really an answer to the one real cost named in this chapter — the coordination horizontal scaling requires. Understanding that GreenMart's regions exist for real, specific reasons (not fashion) makes every mechanism ahead feel like a real answer to a real need, not abstract machinery for its own sake.
GreenMart now has real, honest reasons for why its data lives in three places instead of one, and a clear name for the real cost that choice carries. What actually broke, in the precise terms this Act is building toward, is exactly where the next chapter goes.