How would you deploy a new container version that requires a database schema change while old and new replicas overlap?

Rolling container deployments with database migrations

Coordinates old and new application versions, expand-and-contract schema changes, migration ownership, readiness, and rollback during rolling releases.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The expand release adds nullable columns, new tables, or compatible indexes first. Application code can then write both shapes or tolerate both while a bounded backfill runs. After every replica uses the new contract and data is verified, a later release removes the old column or behavior. This keeps rollback possible during the transition.

Full answer below

Practice focus

Rolling updates, backward compatibility, expand-and-contract, migration jobs, startup races, readiness, rollback, and observability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A rolling deployment means old and new code run at the same time, so the database change must be compatible with both versions. I use expand-and-contract rather than making a breaking schema change in one step.
The expand release adds nullable columns, new tables, or compatible indexes first. Application code can then write both shapes or tolerate both while a bounded backfill runs. After every replica uses the new contract and data is verified, a later release removes the old column or behavior. This keeps rollback possible during the transition.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I do not let every replica race to run production migrations during startup. A controlled pipeline step or one migration job owns the schema change, reports status, and has appropriate locking. Readiness prevents new code from receiving traffic before required compatible schema exists, but startup should not hang indefinitely waiting for a dangerous migration. Large indexes and backfills are planned separately from a request-path rollout.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I preflight affected rows, lock duration, disk growth, and database edition capabilities. Dashboards show old and new image versions, migration state, error rates, and data validation. Feature flags can separate deploying code from activating the new path. Rollback is tested against the expanded schema, while destructive contraction waits until the compatibility window closes. The deployment runbook names the owner and stop conditions so schema progress is not inferred from healthy Pods alone.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Dropping or renaming a column while old replicas still use it.
Running migrations independently from every starting replica.
Combining a large backfill with the application startup deadline.
Assuming image rollback also rolls back data.

Red flagsCandidateSigns the container design is fragileSignals that an interviewer may treat as risky.Open details

Details

Old and new versions require incompatible schemas.
Migration lock contention restarts the whole fleet.
No metric shows backfill progress.
The contraction release has no compatibility evidence.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What is expand-and-contract?
Who should own migration execution?
Why can application rollback fail after a schema change?

Continue the section

Next in Containers & Runtime Essentials: Diagnose container failures

Step 15 of 15

Diagnose container crash loops, image pulls, and OOM failures

Opening drill

How would you deploy a new container version that requires a database schema change while old and new replicas overlap?

Rolling container deployments with database migrations

Coordinates old and new application versions, expand-and-contract schema changes, migration ownership, readiness, and rollback during rolling releases.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

How would you deploy a new container version that requires a database schema change while old and new replicas overlap?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you deploy a new container version that requires a database schema change while old and new replicas overlap?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section