How to manage data needed across different Microservices?

Question

I am currently designing a Microservices-Approach for my company (Logistic Company). Right now we have a monolithic system with a single relational database.

I understand the approach of Microservices of having separate databases. Unfortunately I do not understand how to manage data that is needed in different services. Ie there is data about geo-hierarchy that is needed in invoicing, booking, path-finding and so on. It describes the hierarchy of any place in the world (Ie There is a town located in a county located in a state located in a country located in a continent). In my opinion this data does not belong to any of those mentioned services but is required by any of those.

How can I deal with this kind of data?

One solution I can imagine is an own Microservice for this data, but this would not align with the Domain-Driven Design-Idea of having Services split by functionality and not by service.

Can anyone help me?

Answer 1

When deciding, you're going to want to think about how this data is updated and changes.

Assuming that there will be an occasional need to update this data (eg new towns), the responsibility for managing those updates is a really good candidate for an independent service which contains the authoritative database of the geo-hierarchy.

You then have the choice of how the other services can get the geo-hierarchy data they need.

• They can make queries against the geo-hierarchy service, but this means that unavailability of that service means that they can't accomplish their goals. These services become deeply coupled to the geo-hierarchy service.

• Alternatively, the geo-hierarchy service can publish events describing changes in the geo-hierarchy: other services subscribe to those events and update their own local model containing exactly the geo-hierarchy data they need to accomplish their goals. Because this data is stored alongside the other data they need, it's going to be as available as the other data they own; geo-hierarchy being down only means no updates. Durable log-structured storage systems like Kafka or Pulsar are well-suited to event publishing.

The second approach does require explicitly dealing with eventual consistency (there will be periods of time where not all services agree on what the current state of geo-hierarchy is, just like in the real-world there was a period where some maps had a single Yugoslavia, and others would have some subset of Slovenia/Croatia/Bosnia/Serbia/Montenegro/Kosovo), but there's a similar concern in the first approach (consider what happens when an update happens right after a query but before the querier has finished making use of the results (further: consider caching...)) that's swept under the rug.

One advantage of the second approach is that since the geo-hierarchy service is only needed for making updates, it doesn't have to always be running.

If the data will almost never be updated, it's also worth considering making it static configuration data that can be loaded into the various services. This doesn't avoid the eventual consistency concerns (unless you're willing to shut every service using geo-hierarchy down when you do an update), but it likely saves the cost of a DB (whatever version control or configuration management you store it in is effectively the DB).