Microservice database challenges
A few different ways to keep a service’s persistent data private. For
example, if you are using a relational database then the options are:
- Private-tables-per-service : each service owns a set of tables that must only be accessed by that service
- Schema-per-service : each service has a database schema that’s private to that service
- Database-server-per-service : each service has it’s own database server.
There are some downsides to keeping a service’s persistent data
private.
- It might also make sense to have a polyglot persistence
architecture. For each service you choose the type of database that is
best suited to that service’s requirements. For example, a service that
does text searches could use ElasticSearch. A service that manipulates a
social graph could use Neo4j. It might not make sense to use a
relational database for every service.
- Most notably, it can be challenging to implement business
transactions that update data owned by multiple services. Rather than
using distributed transaction, you typically must use an eventually consistent, event-driven approach to maintain database consistency.
- Another problem, is that it is difficult to implement some queries
because you can’t do database joins across the data owned by multiple
services. Sometimes, you can join the data within a service. In other
situations, you will need to use Command Query Responsibility Segregation (CQRS) and maintain denormalizes views.
- Another challenge is that services sometimes need to share data. For
example, let’s imagine that several services need access to user
profile data. One option is to encapsulate the user profile data with a
service, that’s then called by other services. Another option is to use
an event-driven mechanism to replicate data to each service that needs
it.
