Rearchitecting a SpringBoot service for Database Migration

This post is part of the series on doing safe database migrations using the 4-phase approach. Other posts in the series are (a) Migrating Operational DB to the cloud (b) Data streaming from DynamoDB to ElasticSearch (c ) Data streaming from DynamoDB at scale to ElasticSearch. Risk free data migration explains the 4-phase approach.

When I started my career, everyone was fearful of vendor lock in: we were cautioned against it in university, we were cautioned against it in design/code reviews. Yet, everywhere we used the same database vendor and same programming language. Leads went out of their way to adhere to sql standards so the code is not vendor-specific. A decade later, I’m involved in projects where not only do we write database-specific code, we also migrate out of one system in favor of the other whenever we realize our initial assumptions about the database technology do not hold good anymore. Both the tech world and our customer base and therefore business requirements evolve quickly and we have to adapt or …

Why change the database?

We have a microservice that is built in the latest and greatest of SpringBoot, uses NoSQL database and it continues to grow in customer base and user data. The problem: database doesn’t scale up based on our usage and we are a tiny self-managed team without specific database expertise that would love to focus on delivering additional value to customers rather than spend time operating and fine tuning our…