Conceptual
Login

Serving From a Second Geographic Area Buys One Requirement and Charges You Consistency and Cost

Running in a second geographic area is the largest structural change most designs can make, and it is worth making only when a named requirement demands it. There are three such requirements and they are not the same. Surviving the loss of an entire area, which is rare but total. Serving users near them, when the speed of light across an ocean is a meaningful part of a latency budget. And a rule that data must stay inside a jurisdiction. Each of these is bought differently, and a design that has not said which one it is buying usually buys the expensive parts of all three. The charge is always the same, and it is mostly about data. Two areas far apart cannot both accept writes and stay consistent without paying a round trip on every write, so you choose: one area writes and the other follows behind, or both write and you accept conflicts and resolve them. Everything else is charged too: capacity in both places, moving data between them, a deployment and a configuration that must be correct twice, and a failover procedure that is exercised rarely and therefore trusted least. You can now decide whether a second area is required and say which requirement is paying for it.