BASE Properties

In the last lesson, you learned that ACID guarantees keep your data correct. Atomicity, Consistency, Isolation, Durability, no partial writes, no broken constraints, no interference between transactions, no lost data. Beautiful.

Now here's the problem: what happens when your system spans multiple data centers across the globe?

You have a user in Tokyo posting a photo. That write needs to be saved in a database. But you have three database copies, one in Tokyo, one in Virginia, one in Frankfurt. For ACID to work across all three, they need to agree on the write before it is committed. So the write in Tokyo waits for Virginia and Frankfurt to answer before it can tell the user "Photo posted!"

You can work out roughly what that costs without looking anything up. Light moves through fibre at about 200 kilometres per millisecond. Tokyo to Virginia is on the order of 11,000 km of cable, which is about 55 ms each way, so 110 ms for the round trip before any software runs. Frankfurt is further still. Real routes are longer than the straight line and add switching on top, so treat these as floors rather than estimates.

Now notice what that does to throughput, which is the part people miss. If a write holds a lock while it waits 130 ms for a global acknowledgement, one lock can serve at most about seven writes a second. That is not a hardware limit you can spend your way out of. It is the same round trip, charged once per write, and it is why the largest systems stopped paying it.

So the biggest distributed systems in the world made a pragmatic choice: they relaxed their consistency guarantees. They traded the strict "always correct" promise of ACID for a gentler "correct eventually" promise called BASE. Not because ACID is wrong, but because at internet scale, enforcing it across distributed systems costs more in latency and availability than most use cases justify.