Consistency

Upstash utilizes a leader-based replication mechanism. Under this mechanism, each key is assigned to a leader replica, which is responsible for handling write operations on that key. The remaining replicas serve as backups to the leader. When a write operation is performed on a key, it is initially processed by the leader replica and then asynchronously propagated to the backup replicas. This ensures that data consistency is maintained across the replicas. 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).

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.