Use the expand and contract pattern. First expand: add the new column or table in a backward compatible way so the currently deployed code still works. Then deploy code that writes to both old and new, backfill existing rows in small batches, switch reads to the new shape, and only in a later release drop the old column. Keep every migration compatible with the version of the application running before and after it.
Why interviewers ask this
The interviewer wants to know whether you have shipped schema changes against live traffic or only in development. They listen for expand and contract, for backfilling in batches to avoid long locks and replication lag, and for the decoupling of migration from deploy. Mentioning specific lock hazards, such as index creation, shows genuine production experience rather than theory.
How to structure your answer
- Name the pattern and the invariant: every step is backward compatible.
- Walk the phases in order, expand, dual write, backfill, switch, contract.
- Cover lock and replication hazards and how you avoid them.
- Say how you verify and how you roll back at each phase.
Example answer
The rule I hold to is that any deployed schema has to work with both the previous and the next version of the code, because during a rolling deploy both are running at once. So I never rename a column, I expand and contract. Say we are splitting a name field. First migration adds the new nullable columns, which is cheap and touches no existing rows. Then a release where the application writes both the old and the new shape but still reads the old one, so nothing user facing depends on the new data yet. Then a backfill running in batches of a few thousand with a pause between them, so I do not hold a long transaction or blow out replication lag on the replicas. Then a release that reads the new columns, with the old ones still being written as an escape hatch. Only once that has been stable for a release or two do I stop dual writing and drop the old columns. I also keep migrations out of the deploy path itself, and anything that takes a heavy lock, like building an index, runs concurrently and off peak.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you verify the backfill is complete and correct?
- What is your rollback plan if the read switch goes wrong?
- How would you handle this when the table has half a billion rows?
Related devops engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions