DEV Community

adegiamb
adegiamb

Posted on

Dropping database column and Microservices

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:

  1. Existing deploy micro service to crash.
  2. Random errors to appear in logging.
  3. Alerts to be raised if you have monitoring in place.

Showing Best practice vs combine deployment

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
Enter fullscreen mode Exit fullscreen mode

Top comments (0)