I ran across a post on microservices recently and was intrigued. I always like the idea of loosely coupled, independent items in software. However the idea of microservices causes issues with databases. Here’s the section in the piece by Netflix: Create a separate data store for each microservice.

I tend to think of microservices is very small, tightly bound components of software. If that’s the case, how can I separate each item in a database? Do I want dozens of databases?

I got in an argument with a developer a few months ago about this. The developer was sure that having separate databases (or stores) for each component wasn’t an issue. For things like banking and similar transfers, I’m not sure a microservice can be separated safely and still ensure integrity.

This is a tough concept for architecture, and I need to read more and understand how this could work in practice. I suspect that in places where things could be separate, you could easily use schemas in a database to separate out microservices from each other. If each service includes its own connection information, then using schemas would work and still allow for scale out to other databases if needed.

This is an area that certainly fits larger scale applications like Netflix and Spotify, but for many of us, our applications seem to be more tightly tied together.

Or are they?

Microservices are much like Service-Oriented Architecture (SOA), which I think fits many applications. I’m not sure how similar the concepts are, but this is certainly an area I’d like to learn more about.

Filed under: Blog Tagged: database design, software development, syndicated