Redis / Advanced: persistence, distribution and operations / Lesson 18

Recovery, evolution and release reliability

Plan key-model and service changes as observable, compatible and recoverable transitions. Distinguish cache rebuild from restoring authoritative Redis data and coordinate write ownership at cutover.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Design versioned values, bounded migration and convergence evidence.
Verify restore, client and writer-ownership prerequisites before release.

Pin supported assumptions and the actual service product

This course reviews Redis Open Source 8.2 as an extended-release baseline against official documentation on 2026-10-25. Newer command forms are labeled rather than assumed available. Redis Open Source, Redis Software and Redis Cloud release numbering and lifecycle policies are separate; managed compatibility can restrict commands and operational access. Verify the specific patch/support policy and client library before upgrading. A running binary or green endpoint does not prove key compatibility, ACL correctness, persistence recovery or application retry safety. No deployment, configuration, migration or live database command is performed by this course.

Expand compatibility before switching key authority

A value-format change should define old/new readers, writers, invalidation and expiry before the first mixed rollout. The JSON below records a fictional transition from version 1 to version 2 and an explicit fallback policy; it is not an executable migration. Add compatible reading, deploy new writes, rebuild or backfill bounded data, and verify convergence before removing old interpretation. Cache keys can be invalidated and rebuilt only when the source and reload budget permit it. Authoritative stream or queue data needs a stronger history-preservation plan than deleting a prefix.

json Nonexecuting compatibility-transition plan

{
  "keyFamily": "lab:profile",
  "oldVersion": 1,
  "newVersion": 2,
  "readerPolicy": "accept-known-versions-during-overlap",
  "fallback": "bounded-authoritative-load",
  "retirementGate": "verified-convergence-and-consumer-readiness",
  "productionTarget": false
}

The record creates no keys or rollout. Its retirement gate is a requirement to verify, not evidence that consumers are already ready.

Choose rebuild or restore from the authority contract

An ordinary cache can sometimes be rebuilt from an authoritative source, while sessions, pending work and retained events may require protected Redis recovery artifacts and application reconciliation. Rehearse the selected method in isolation, including versions, required secrets, expiry interpretation and consumer state. Do not restore a test copy as a second active production writer or allow scheduled/outbound effects to contact real users. Verify artifact independence and measured recovery duration rather than calling a successful file transfer a complete recovery. Keep original evidence and untouched artifacts available under the approved process before any repair decision.

Check known-version compatibility explicitly

The local validator accepts only declared versions with their required field names. A version-2 label without the expected new field is rejected, while unknown version 3 is not guessed. This is an application compatibility test, not Redis schema validation or a complete migration checker. Real evidence must include every producer and consumer, the serialization contract, TTL behavior and invalidation. If code silently accepts unknown versions or combines fields from incompatible schemas, a rollout can appear available while returning incorrect state. Keep failure and fallback behavior visible rather than turning malformed data into an empty success.

python Offline mixed-version compatibility cases

def compatible(value):
    if value.get('version') == 1:
        return 'name' in value
    if value.get('version') == 2:
        return 'display_name' in value
    return False

assert compatible({'version': 1, 'name': 'Lina'})
assert compatible({'version': 2, 'display_name': 'Lina'})
assert not compatible({'version': 2, 'name': 'Lina'})
assert not compatible({'version': 3, 'display_name': 'Lina'})

Two declared complete versions pass; an incomplete new shape and an unknown version fail. No server data is read, migrated or deleted.

Define the last safe rollback point and one writer policy

Before cutover, verify client routing, command availability, ACL/TLS, key placement, persistence, backups and workload behavior. Once a destination accepts unique authoritative writes, switching the endpoint back without history reconciliation can lose or fork business state. Fence old writers where required, record the accepted authority and retain a tested recovery path. For cache-only migration, also budget cold misses and source impact. A release decision should state what was verified, what remains uncertain, who owns the remaining risk and when it will be reviewed. A successful connection is evidence of connectivity, not complete release correctness.

Common errors and fixes

A key prefix is deleted as a universal migration strategy

Why it happens: Disposable cache and authoritative work/history were not distinguished.
How to fix it: Review authority, retention and recovery before any destructive operation.
Prevent it next time: Classify each key family’s loss and rebuild contract.

Old consumers misread a new value format

Why it happens: Producer rollout preceded compatible consumer handling.
How to fix it: Restore compatible reading and stage the transition under review.
Prevent it next time: Test old, new, incomplete and unknown shapes together.

Rollback discards destination-only writes

Why it happens: Endpoint reversal was mistaken for data-safe history reversal.
How to fix it: Fence writers and reconcile through the rehearsed recovery process.
Prevent it next time: Define rollback eligibility before the first authoritative destination write.

Check your understanding

1. A new cache format deploys safely, but all keys are cold. What must release verification include?

Show worked solution

Measure or model bounded reload demand, source capacity, admission and fallback behavior under the approved scenario. Compatibility alone does not prove the authoritative service survives a broad cache rebuild. Keep TTL and refresh policy within freshness requirements and avoid claiming success merely because Redis accepts the new serialized bytes.

2. Why is pointing clients back to yesterday’s Redis endpoint insufficient rollback for authoritative stream processing?