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).
Checkout Read Your Writes for more details on how to achieve RYW consistency.
Checkout Replication for more details on Replication mechanism.
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.
