The schema had to change. The database team added a new column, and nothing else could move forward until it was live in every environment.
Adding a new column sounds simple, but in production systems the risks compound fast. Data loss, degraded queries, broken APIs—one wrong migration can ripple through every dependent service. The goal is to make the change atomic, predictable, and reversible.
The first step is clarity. Define the exact column name, data type, constraints, and default values. Confirm the column’s placement in the table and ensure it matches the domain model. Decide whether it can be nullable, or if you need to prefill data before making it non-nullable.
Leverage feature flags and staged rollouts for minimal downtime. Ship the migration script separately from the code that uses the new column. This allows you to deploy the schema first, verify it, and only then update the application logic. In high-traffic environments, consider adding the column without constraints, backfilling data in batches, and applying indexes or constraints in later steps to avoid locking the table for long periods.