Learn the vocabulary of migrating a production schema without a service interruption.
0 / 5 completed
1 / 5
At standup, a dev mentions migrating a production database's schema while the application keeps serving live traffic throughout, with no scheduled maintenance window or outage. What is this practice called?
A zero-downtime migration changes a production database's schema or underlying structure while the application continues serving live traffic throughout, avoiding a scheduled maintenance window or outage entirely. Taking the application offline during a maintenance window is simpler to reason about but is increasingly unacceptable for a service expected to be continuously available. Achieving zero downtime requires carefully sequencing the migration into backward-compatible steps rather than a single all-at-once change.
2 / 5
During a design review, the team wants to add a new required column to a table without breaking currently deployed application code that doesn't yet know about it. Which technique supports this?
The expand-and-contract pattern breaks a schema change into safe, backward-compatible stages: first expanding the schema by adding the new structure alongside the old one, migrating application code and data gradually, and only later contracting by removing the old structure once nothing depends on it anymore. Adding a new required column and immediately deploying code that assumes it exists everywhere risks breaking any instance still running the previous version during a gradual rollout. This staged approach is a foundational technique for achieving a genuinely zero-downtime schema change.
3 / 5
In a code review, a dev notices the migration writes to both the old and new data structures simultaneously for a transition period, before eventually cutting over reads to only the new one. What does this represent?
A dual-write with a phased cutover writes new data to both the old and new structures simultaneously for a transition period, keeping both in sync while the team gradually migrates reads over to the new structure and verifies correctness before fully cutting over. Writing exclusively to the new structure immediately risks the old structure becoming stale for any code path still reading from it during the transition. This phased approach reduces risk by allowing verification and rollback throughout the migration rather than committing to it in a single irreversible step.
4 / 5
An incident report shows a zero-downtime migration broke production because a newly deployed application version was rolled out before the corresponding schema change had been fully applied everywhere. What practice would prevent this?
Carefully sequencing schema changes and application deployments so each intermediate step stays backward-compatible ensures a version still running during a gradual rollout doesn't break against a schema it wasn't built to expect. Assuming every instance updates at exactly the same instant ignores the reality of a gradual, staggered deployment across many instances. This sequencing discipline is precisely what the expand-and-contract pattern exists to enforce.
5 / 5
During a PR review, a teammate asks why the team performs this schema change as a zero-downtime migration instead of scheduling a brief maintenance window to make the change more simply. What is the reasoning?
Scheduling a brief maintenance window inherently causes a real, user-facing service interruption, even if it's brief and planned in advance. A zero-downtime migration avoids that interruption entirely by carefully staging the change into backward-compatible steps applied while the service keeps running. The tradeoff is the added engineering complexity and time required to plan and execute that staged sequencing, compared to the relative simplicity of a single change made during an offline maintenance window.