Replication

What you'll walk away with

Explain the core ideas behind Replication
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

Redis replication sends leader writes to replicas asynchronously and supports partial or full resynchronization after reconnects. An acknowledged write can be lost if failover happens before replication, and replica reads can be stale. WAIT requests replica acknowledgements but does not turn Redis into a strongly consistent store.

Connect it to a real scenario

Route only stale-tolerant catalog reads to replicas. Read new sessions from the leader when immediate read-after-write is required. Monitor offsets, lag, link status, full-sync frequency, and backlog size; test data loss during failover.

Replication is asynchronous
Replica reads can be stale
WAIT is not strong consistency

Try the working example

shell

INFO replication
ROLE
WAIT 1 1000
CONFIG GET repl-backlog-size
CONFIG GET min-replicas-to-write
CONFIG GET min-replicas-max-lag

You should see

You can inspect role, replica connectivity and offsets, plus acknowledgement count.

5-minute try-it

Create a matrix deciding whether catalog, session, and rate-limit reads may use replicas.

One important caution

Do not claim two replicas guarantee zero data loss; failure timing and asynchronous lag still matter.

Redis — Replication — Redis

Easy traps

Do not claim two replicas guarantee zero data loss; failure timing and asynchronous lag still matter.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Create a matrix deciding whether catalog, session, and rate-limit reads may use replicas.

You'll know it worked when: You can inspect role, replica connectivity and offsets, plus acknowledgement count.