# Source: https://upstash.com/docs/redis/features/consistency.md

> ## Documentation Index
> Fetch the complete documentation index at: https://upstash.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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).

Checkout [Read Your Writes](/redis/howto/readyourwrites) for more details on how to achieve RYW consistency.

Checkout [Replication](/redis/features/replication) for more details on Replication mechanism.

<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`.
</Note>