Prove both sides of a schema transition
What This Concept Is
A safe release sequence considers old and new readers and writers during the entire coexistence and rollback window. Migration success alone is narrower than application compatibility.
Why It Matters Here
The capstone inherits Semester 09 release reasoning but must demonstrate it on its own data model.
Concrete Example
Add an optional field, deploy tolerant readers, introduce writers and backfill idempotently, then verify old-reader compatibility before later contraction. Test records created before and after the change. If old code fails on a new value, the rollback boundary has changed and must be explicit.
Common Confusion / Misconception
A database migration tool reporting success does not verify all clients. Restoring a backup can lose valid writes made after the backup and needs reconciliation.
How To Use It
Write a version-pair matrix and test it against the capstone datastore. Define stop conditions, backup/restore purpose and an irreversible-step boundary. Retain artifact identity throughout.
Check Yourself
Which reader rejects the new representation? Can backfill be retried? At what point does image rollback cease to be sufficient?
Mini Drill or Application
Run the original staged release with old/new fixtures and an injected regression. Verify recovery through the actual user path and data checks.
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.