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
.