Separate software rollback from data recovery

What This Concept Is

Rollback changes a software version. Recovery restores a usable service and valid data. These overlap only when old software remains compatible with data and external effects produced during the release.

Why It Matters Here

The release lab must test the return path before a production-style claim.

Concrete Example

A new writer stores an enum value the old reader rejects. Rolling the image back restores old code but causes read failures. An expand/contract sequence can keep both readers compatible during the rollout window; contraction occurs only after old consumers and rollback needs are resolved. External payments cannot be undone by changing an image.

Common Confusion / Misconception

A successful rollback command is not a verified recovery. Backup restore can discard later valid writes, so it requires an explicit data-loss decision and reconciliation.

How To Use It

Document reader/writer compatibility, migration order, stop conditions and effects that need compensation. Test old and new readers against records written by each version. Verify user paths and data after abort.

Check Yourself

Which writes survive rollback? What is the compatibility window? Which effects require business compensation?

Mini Drill or Application

Add a versioned record to the original canary exercise and intentionally introduce an incompatible reader. Repair the migration plan and show the rollback test now passes.

Read This Only If Stuck

Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.

SLSA v1.2 verification; Google SRE canarying; DORA metric definitions.