Q: How do you handle zero-downtime database migrations in a distributed application?

Add new columns or tables without destructive constraints. Never rename a column directly. If transitioning from `phone` to `phone_number`, add `phone_number` as a nullable column. Run this migration in CI before deploying code.

-- Step 1: Add new column safely
ALTER TABLE customers ADD COLUMN phone_number VARCHAR(32);

Deploy Application Version 2.0. The code writes new data to BOTH `phone` and `phone_number`, but continues reading from `phone`. If a rollback to Version 1.0 is required, Version 1.0 remains 100% operational because `phone` is still updated.

Run an asynchronous background worker to copy historical values from `phone` to `phone_number`. Execute backfills in small indexed batches (e.g. 5,000 rows with sleep intervals) to prevent table locking or replication lag.

-- Batch backfill query with sleep to avoid locks
UPDATE customers 
SET phone_number = phone 
WHERE id BETWEEN 1 AND 5000 AND phone_number IS NULL;

Deploy Application Version 2.1 to read exclusively from `phone_number`. Add NOT NULL constraints using `VALIDATE CONSTRAINT` (which avoids table locks in PostgreSQL). In a subsequent sprint, drop the legacy `phone` column once zero services query it.