Skip to main content

Consistency

Upstash uses a leader-based replication mechanism. Each key is owned by a leader replica and other replicas become the backups of the leader. Writes on a key are processed by the leader replica first then propagated to backup replicas asynchronously. Reads can be performed from any replica.

Each replica employs a failure detector to track liveness of the leader replica. When the leader replica fails for a reason, remaining replicas start a new leader election round and elect a new leader. This is the only unavailability window for the cluster where write your requests can be blocked for a short period of time. Also in case of cluster wide failures like network partitioning (split brain); periodically running anti entropy jobs resolve the conflicts using Last-Writer-Wins algorithm and converge the replicas to the same state.

This model gives a better write consistency and read scalability but can provide only Eventual Consistency. Additionally you can achieve Causal Consistency (Read-Your-Writes, Monotonic-Reads, Monotonic-Writes and Writes-Follow-Reads guarantees) for a single Redis connection. (A TCP connection forms a session between client and server).

note

Previously, Upstash supported Strong Consistency mode for the single region databases. We decided to deprecate this feature because its effect on latency started to conflict with the performance expectations of Redis use cases. Also we are gradually moving to CRDT based Redis data structures, which will provide Strong Eventual Consistency.