How to model communication among microservices in case of delegated persistence logic

Question

I would like to ask here regarding following situation.

Lets say we have 2 applications or "(micro)services":

• app A sits on top of big datastore and exposes data via REST, it is typical Spring Boot app which needs to manage permissions, do some transformations and mapping etc. and it enacapsulates the necessary low level data api, which is rather complex.

• second app B responsibility is to implement core business logic for certain domain. This app also has its persistence layer, i.e. its own local data store. However it is also heavily dependent on app A as app A centralizes access to that big data store.

In my understanding I would state Apps A and B are standalone applications/services each specialized on its task. However does it make any difference or unwanted consequences, when someone would think of that A-B relationship in the way app A is actually "persistence layer" of app B, i.e. together with its "local persistence logic" and thus same module. This can be thought of as implementing Dao or Repository interfaces with some REST implementations calling app A under the hood in data layer/module.

In my opinion I would rather see that as a typical integration case and I would not mix local persistence logic (of own datastore) with this delegated data API provided by app B. I see that as another regular service, not a "remote sub-module" of app B sitting in B data layer.

Im hoping above description is enough understandable. Currently I would like to see, if any preferrence here implies real and rather unwanted consequences or it is just a matter of personal taste.

Many thanks, for any comments.

Answer 1

This is a bit opinion-based as there is not a "right" and "wrong" way to tackle it. But, that's often the case with architectural questions, so I'll take a shot.

There are three paths I'd consider for your scenario:

1. If App A is a single repository that holds the data for all or most of your services, it probably needs to be broken up to move persistence within the domain of each service boundary.
2. If App B is a special case with very closely-related data to App A and both services provide required features (that don't overlap), consider connecting App B directly to the database and putting both services behind a facade that represents that particular domain.
3. If all App B is doing is really providing an interface to the data in App A, it's possible your service boundaries are drawn wrong and the two could/should be combined.

Adding an extra HTTP API call in the chain between client and data persistence (using App B as an "interface" to the data in App A) is going to be a big challenge to keep performant and is something I'd avoid. If, after careful evaluation, the current boundaries are determined to be the best, you might look into a faster or more synchronous way to communicate with the big datastore in App A - like gRPC or something similar.

Having multiple services share a persistence layer is also generally not desirable, but if there really are multiple different business domains operating on essentially the same dataset, it's not unheard of. An example of where this might make sense is a service that stores/manages addresses and a separate service using the same datastore that validates addresses with an external API.

Service boundaries should represent business domain boundaries and those rarely (but not never!) include a single, large datastore. So, focus on making sure App A and App B are appropriately independent according to their business function and your answer may become more clear.