We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Data Replication Distribution
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Data Replication Distribution
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Here's a fact that humbles every engineer eventually: the speed of light is finite.
If your user is in Tokyo and your database is in Virginia, every single read request has to travel roughly 11,000 kilometers each way. Even at the speed of light through fiber, that's about 70ms for the round trip. And that's the theoretical minimum. In practice, with routing hops and processing, you're looking at 150-200ms.
No amount of clever code fixes physics. You can optimize your queries down to 1ms, but if the data has to cross the Pacific Ocean twice, your user still waits 200ms before seeing anything.
Netflix figured this out early. They didn't try to build faster networks. They moved the data. Their Open Connect boxes sit inside ISP data centers, putting movie data within a few milliseconds of the viewer. Cloudflare does the same thing with their 310+ points of presence, web content in the same city as the user.
Data locality, the practice of keeping data physically close to where it's consumed, is the single most impactful performance optimization at scale. Not better algorithms. Not faster hardware. Just putting the bits closer to the people who need them.
Data locality is a simple principle: store data near the compute or users that access it most.
This applies at every layer of a system:
Hardware level. CPUs access L1 cache in about 1 nanosecond, main RAM in about 100ns, and SSDs in about 100,000ns. The closer data is to the processor, the faster operations run. This is why databases keep "hot" data in memory. Postgres shared_buffers and MySQL innodb_buffer_pool exist specifically to keep frequently accessed pages in RAM.
Network level. Data on the same machine has zero network . Data in the same data center might be 0.5ms away. Data across the country is 30-70ms away. Data across the ocean is 100-200ms away.
Application level. If 90% of a user's requests touch their own profile data, it makes sense to keep that profile data on a server geographically close to them. CockroachDB's locality-optimized search and DynamoDB's global tables both address this.
| Data Location | Access Time | Example |
|---|---|---|
| CPU L1 cache | ~1ns | Currently executing instruction |
| RAM | ~100ns | Cached database page |
| Local SSD | ~100,000ns | Database table file |
| Same data center | ~500,000ns | call |
| Cross-country | ~30,000,000ns | US East to US West |
| Cross-ocean | ~150,000,000ns | US to Asia |
That's a 150-million-fold difference between the fastest and slowest options. Data locality is about making sure the data you need most is as high up that table as possible.