intermediateDistributed Systems — Replication, Partitioning & Consistency

A write to your distributed database succeeded but the user can't see their update. What could be happening and how do you fix it?

Root causes: 1) Read-after-write inconsistency: write went to primary/leader; read went to a replica that hasn't replicated yet. Solution: read-your-own-writes guarantee. In MongoDB: use causally consistent sessions. In Cassandra: use QUORUM for both reads and writes. 2) Load balancer routing: user's GET request routed to different server that has stale cache. Solution: sticky sessions for that us

This is a Pro chapter

Sign in, then upgrade to Pro or Power to unlock this and the full Databases Mastery library.

A write to your distributed database succeeded but the user can't see their update. What could be happening and how do you fix it?

Next Step

Continue to What is the difference between cache-aside and write-through caching?← Back to all NoSQL questions