I am developing an app and splitting this into microservices. The app is a booking system. There are two microservices - 1), bookings and 2) company details.

For the bookings microservice, this contains entities such as customers, bookings, services, etc etc. All these entities are related to each other @ the database level.

What I am wondering is, should each of these entities (bookings, customers, services, etc) be their own API and microservice? If so, how would I then handle relationships?

  • If your entities form a common domain with interconnected objects on database level, why use different microservices at all?
    – mtj
    Apr 29, 2020 at 6:45

3 Answers 3


A microservice per entity is generally bad design because it will lead to all services talking to all other services.

By definition, microservices need to have their own database and be able to autonomously perform their business capability, but you can rarely do any business logic with a single entity.

For example, to manage bookings you'll need some information about the booking, some about the customer and some about the services. To manage testimonials, you'll also need some information about the customers, the bookings, and maybe the services as well. The point is that not every microservice will need all the information about every entity.

The result is that you won't have a single place with all the information about a Service. You'll have the service description and pictures in one service, the service price in another, the service testimonials and ratings in another, etc. The same will happen with the customers, for which you'll have their name and email somewhere, their preferred services somewhere else, and their payment information somewhere else again.

The important is that when a microservice needs to execute an operation, it can get all it needs (or almost at least) from its database instead of having to call 10 other microservices which in turn will call 10 other microservices.

Regarding your concern about data integrity. Well, this can be considered a drawback of microservices. They have their own DBs (or separate schemas in the same DB) and having Foreign Key relationships between tables from different microservices should never be done. Therefore, you cannot enforce data integrity at the database level.


this contains entities such as customers, bookings, services, etc etc. All these entities are related to each other @ the database level.

It is actually how a monolith system looks like.

What I am wondering is, should each of these entities (bookings, customers, services, etc) be their own API and microservice?

The only ones capable to answer to this question is probably you, product owner and different stakeholders. So those who knows the business, their entities and their relation between them.

Don't forget that the goal is not the microservices design.. it just the strategy.

Focus on outcomes and depending on them maybe you'll see that the monolith approach is better.

You should be thinking of going to a microservice architecture in order to achieve something that you can’t currently achieve with a monolith one.

Regarding relationship, if you go to a microservices approach customers and booking tables will end up living in different schemas, so what happens with our foreign-key relationship? We have two key problems to consider. First, how correlate entities if it can no longer do this via a database join? The other problem is, what do we do about the fact that data inconsistency could now exist..

Your database joins will be replace by service calls (API call). Now you should take care of latencies. It will be probably slower than db calls but slower can be acceptable if it fast enough for you. Using a tracing system like jagger or zipkin will provide help to measure latencies between your services.

Regarding consistency the true challenge is the split of your business transaction. When you could handle all your relations inside a single local transaction now you have to handle multiple local transactions and more important compensating transactions. Take a look at SAGA pattern. You can see that as chaining local transactions and create compensating transaction to handle rollback.

When you start considering effectively breaking foreign-key relationships, one of the first things you need to ensure is that you aren’t breaking apart two things that really want to be one. You should look about the concept of Aggregate.


It's a matter of choice really. If your application calculate the result of 2 + 2 a lot of times and is highly dependent on it, then this simple procedure might be converted to a microservice.

I recommend you to check what bounded context is. If you define your bounded context points, then it is easier to decide which part of your application souls be seperated as a service.

  • I've looked at that. The "bookings" boundary context makes sense to me, with all it contains. There's no must size for a microservice but there are quite a lot of entities (bookings, customers, services, testimonials, etc). Each microservice should work with independent data so this seems to be the lowest boundary I can find. However, just wanted to check how people deal with relationships. Apr 28, 2020 at 21:58
  • I understand. It's a really a try and see situation. I hope a better and detailed answer show up soon.
    – arkantos
    Apr 28, 2020 at 22:04
  • I could do seperate services for each but then I will need to have an ID pointing to a row in a table in another database. This will have a serious risk that with no referential integrity, data could become garbage. Apr 28, 2020 at 22:08
  • Why do you create another database? All of these microservices can be persisted to a single db. If the problem is redundancy, a db instance on a cluster will do. Seperating every microservice in db level seems costly to me.
    – arkantos
    Apr 28, 2020 at 22:15
  • Isn't that the best practice? Seperate db per microservice for scalability. All those entities I list above currently sit in one database which makes querying and presentation of data easy. The only alternative is split into individual microservices (customer, bookings, vehicles) but on the child side of the relationship I need to store the ID of the parent side (like in a traditional relationship). I can of course see why direct db calls are prohibited. Apr 28, 2020 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.