3 ms·
Nitpicky terminology choices aside, this is a very good, easy-to-follow writeup on multi-region data system design. Understanding that the trick is shuffling ar
by dclowd9901 3y ago
Nitpicky terminology choices aside, this is a very good, easy-to-follow writeup on multi-region data system design. Understanding that the trick is shuffling around the latency makes it much easier to reason about where you want to focus your latency savings. One thing I wasn't quite sure on, though, is why Database A would care if Database B had a read of a certain kind (vs. a write). Reads don't change state, so if a million reads occur with no writes, the data should still be consistent, no?
- zknill 3y agoIf you're talking about the case where a local database forwards a read to the 'leader', and that read is put on the leader's log, but that read is only served when the read is replicated in the log back to the original local database then: It's actually less about the the leader caring about the read, and more about creating a point in time that the read will happen. The database is using the read in the log as the point-in-time where that read happened. The writes before that point will be viewed by the read, and the writes after won't be. By sending the read to the leader, when we receive that read back, we know for sure that all the writes that should have been replicated to our local copy have been replicated (because our read has made the full round-trip that all our writes would have, so we're guaranteed to have received all the writes before that read's "point-in-time").
- dclowd9901 3y agoOh, the author! Great work on the article, and thanks for the answer!