Shared entity/table design for microservices

Question

We are in the middle of breaking a big monolithic e-commerce application into microservices. (We plan to use Java, Spring, Hibernate) We have concept of fulfillment items and persistent items in our monolithic application. Our plan is to mostly break up the fulfillment item CRUD operations and persistent item CRUD operations into two separate APIs. But we have some common entities/tables that both the API's will end up needing. What is the best way to handle this scenario?

Currently one of the options open on table is to have one microservice own the entity/table and have a READ ONLY object reference in other microservice. Are there any drawbacks to this?

Answer 1

Depends a lot on your deployment strategy. If you going to bundle/package both the APIs into one then it's ok if both share the same entities(infact you should not duplicate entities). I would prefer having all the entities and repositories/DAO into one common bundle/package just to expose various APIs for crud operations(without any other business logic). And then my other components will consume these APIs and will have the business logic.

Answer 2

There really isn't much of a drawback except in situations where a micro service cannot operate under eventual consistency. And even in these cases, you can always add a dependency for your non-common micro service to know how to query the common micro service for relevant updates if necessary, although that's less than ideal.

You will likely have to introduce some form of mediator mechanism for your use case though. Something like a JMS broker is an ideal choice that would allow one micro service to inform other interested micro services that something occured so that they each can handle the event in their own way.

For example, a CustomerMessage could be raised that contains the customer's id, name, address, and perhaps credit-limit and one micro service may only be concerned with the id and name while another may be interested also in the address and credit-limit.