ORIGINAL COMPANY-CONTEXT PRACTICE
Migrate a multi-tenant schema without breaking older clients
Original practice scenario: A hypothetical enterprise database service adds a required field while tenants upgrade at different speeds. Propose a migration and rollback strategy.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Expand compatibility before enforcing the new requirement. Schema deployment, data backfill and client adoption are separate phases whose order determines whether old clients continue to work.
Work through it
- Add the new representation in a backward-compatible form and define how old writes are interpreted, using a derivation or explicit unknown state rather than invented business data.
- Backfill incrementally with progress checkpoints and validation, then compare old and new read paths for representative tenants.
- Switch writes and reads under controlled versions, monitoring incompatible clients before enforcing constraints and defining what rollback can safely reverse.
Tradeoffs to discuss
- Dual representations ease gradual migration but increase consistency obligations; a coordinated cutover reduces that period while increasing release coupling.
Common pitfalls
- Do not drop the old field before all dependent readers and rollback paths are understood.
- A successful backfill query does not prove that writes arriving during the backfill were handled correctly.