Redis medium
By default, Redis replication is asynchronous. What is the specific consistency risk associated with this design?
- A Replicas may periodically overwrite the Master's state if their internal clocks are slightly ahead of time.
- B A Master crash immediately after acknowledging a write can result in data loss if not yet sent to Replicas.
- C Redis automatically locks the entire keyspace for all reads once a replication lag of 100ms is detected.
- D The database engine requires a 2-Phase Commit on every write to ensure that all secondary nodes are in sync.
Answer: B. A Master crash immediately after acknowledging a write can result in data loss if not yet sent to Replicas.
Redis prioritizes performance. If a write had to wait for replicas on the other side of the planet, latency would spike. This 'Async' model means that for a few milliseconds, the Master and Replicas are out of sync.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?