Data locality and replication

Data locality and replicationthe part that decides whether multi-region even works

Stateless services are easy to spread; data is the hard constraint. A cross-region database call adds 60–150 ms of speed-of-light tax every time, so a chatty path that hops the Atlantic per request will be slow no matter how good your edge is. The design goal is to keep each request's data reads inside its own region.

• Read-local, write-where-it-makes-sense: serve reads from a same-region replica; route writes to the owning region or use a database built for multi-region writes if conflicts are rare.
• Pin a user's session to a home region so their hot data stays close and you avoid replication-lag surprises mid-session.
• Keep large/cold artifacts (indexes, blobs) in regional object storage replicated lazily, not in the synchronous request path.
• Name your consistency choice out loud: strong within region, eventual across regions and which user-visible operations can tolerate which.