Design a System to Handle Schema Migration

To handle schema migration on a live system like LinkedIn's, I would avoid blocking DDL operations entirely. My strategy follows a four-step phased rollout. First, I would modify the schema to add the new column as nullable, ensuring the change is non-blocking and immediate. The application code must be updated to write to both the old and new columns during this phase to maintain dual-write compatibility. Second, I would deploy a background worker to migrate existing data asynchronously. This decouples the heavy lifting from user requests, preventing latency spikes. Third, once the backfill is complete, I would update the read logic to prefer the new column while still supporting the old one for safety. Finally, after confirming stability, I would remove the legacy column. For blue/green deployment, I would spin up a new environment with the migrated schema alongside the production cluster. We would gradually shift traffic using a load balancer while running validation checks. If anomalies appear, we instantly revert traffic to the blue environment. Rollback plans involve keeping the old schema active until the final cleanup, allowing us to simply switch off the new code path if critical issues arise, ensuring zero data loss or service interruption.