Image generated by AI
A prevalent mistake I see people make while re-platforming a monolith to micro-services is what I’d call database sprawl. 😵💫
Database Selection
Micro-services promises that different workloads can use the best-suited databases.
For example, one part of your monolith might benefit from a relational database, but another might be better suited for a key/value store.
With micro-services, you can have both!
One service could use a relational database, and another could use a key/value store. Problem solved, right?
Yes, with this simple example.
Database Sprawl
The problem starts when you break up a giant monolith into many services.
If left unchecked you may end up using far too many database technologies.
- 📊 Service 1 needed a relational database, so we used
- ⚡️ Service 2 needed in-memory caching, so we used
- 📄 Service 3 needed key/value but better persistence, so we used
- 🗃️ Service 4 needed to store lots and lots of data, so we used
- 📡 Service 5 needed replication, so we used
It’s great to be able to pick the right tool for the job; micro-services let you do that. However, having too many options can be an operational overhead.
Each database technology you use adds to your management burden. If you run your own databases, that’s a lot of infrastructure to deal with.
Even with managed databases, your teams need to know the nuances of each database technology, which becomes more cognitive load.
More databases means more dependencies and tech debt over time. All things that prevent you from delivering value.
Of course, I’m not advocating sticking to just one database type, while many folks will tell you to stick with Postgres or MySQL and you don’t need anything else.
My advice is a bit more nuanced
Before building anything, consider the various use cases and requirements you will need, such as fast caching, storage of large amounts of data, ACID, replication, etc.
Find what databases fit multiple needs and create a more curated list of options.
You may need a few specialty databases for specific use cases, but select from this curated list as you build your micro-services.
A small list of default choices is better than an unmanageable buffet of options.
Top comments (0)