Most of the time, you don't think a lot about making database changes, but when dropping a column, some serious effects on your application can happen if not handled carefully.
As you see in the diagram below, when you deploy a new version of your service with a drop column migration, you have a race condition of the existing micro service (v1) may try to access the column that was removed, causing:
- Existing deploy micro service to crash.
- Random errors to appear in logging.
- Alerts to be raised if you have monitoring in place.
Use a Multi-step Deployment Strategy
Step 1: Deploy New API Version v2
A version of your service that doesn't access the database column you want to drop
Step2: Keep Old Column but Stop Using It
Leave the column in the database. This will ensure that the existing version (V1) does not encounter an issue if it continues to attempt to access the database column.
Step 3: Wait Period for confirmation of no side effects
Leave the column you want to remove in production for a short time to verify that everything is working fine. Usually, a week or two is more than enough.
Step 4: Drop Column via separate Migration
Create a new deployment that should only contain a migration script that drops the unused column.
Optional 1: Ensure All Services Use v2 or greater of the API
Before deploying to production, confirm that all running versions contain your previous changes to remove access to the field you want to drop.
Optional 2: Run DB Backup + Validate Logs
Depending on your environment's setup, you should create a database backup before dropping the column.
note: In most cases, if you leave the column in production for a week, dropping should be fine. But as the saying goes, it's better to be safe than sorry.
Safe Deployment: No Crashes, Clean DB
Now that you know that all running services don't access the column, you can safely deploy the migration to drop the column without worrying about causing an outage.
Mermaid code
Below is the mermaid code to generate the diagram above
graph TD
%% Problem Path
A[Deploy New API Version + Drop Column in Same Release] --> B[Race Condition: Some Services Still Use Old Column]
B --> C[App Crashes / Data Access Errors]
%% Solution Path
A -. Best Practice .-> Best1[Step 1: Deploy New API Version v2]
Best1 --> Best2[Step 2: Keep Old Column but Stop Using It]
Best2 --> Best3[Step 3: Wait Period for confirm no side effects]
Best3 --> Best4[Step 4: Drop Column via sperate Migration]
%% Optional Checks
Best4 --> BestOptional1[Ensure All Services Use v2 API]
BestOptional1 --> BestOptional2[Run DB Backup + Validate Logs]
%% Final State
BestOptional2 --> Z[✅ Safe Deployment: No Crashes, Clean DB]
style A fill:#fb9902,stroke:#c00,stroke-width:2px
style C fill:#f66,stroke
style Z fill:#099,stroke
Top comments (0)