2 angles I think DB designers don’t often think about:
1. Durability extends to the client. Replicated db might ack a write to client, but what if that ack gets lost on the way back over network? If client talks to the DB over simple HTTP, the write might first look like a failure. Can the client retry?
2. Human perception times are biological and don’t change much. But everything in the tech stack has gotten so so much faster since the 80s. Throughput matters, sure, but latency (relatively speaking), is much less of a constraint now than it was.
1) you ack the ack, then ack the ack ack ;)
2) depends, i have a database that farks up a pretty complex distributed system when clients write from another az, latency really can be an issue for some workloads