I'm trying to understand the database per service pattern in microservices architecture.

Say we have a restaurant reservation application composed of the following microservices:

  • User
  • Search
  • Restaurant
  • Reservation
  • Search
  • Notification

If a user wants to create a reservation, the UI would perform a POST request to /api/reservation with the data in the request body.

Would the Reservation database be required to store redundant data from the User database (user_id, username, first name, last name)?

Or would it only store a user_id reference owned the User database?

2 Answers 2


Reservation service has no reasons to know the first or last name of the user, nor his age, sex or e-mail address or phone number. What the reservation service needs to know is the link to a given person reserving the table, and that would be the user's unique identifier.

Later, when a reservation needs to be displayed, with the associated person's first and last name and probably the phone number (to be able to contact the person in a case of a problem), the application displaying this information will do two calls to two services: reservation service, and, from there, the user service (specifying the identifier of the user).

Microservices architecture is not an excuse to duplicate data. If you do that, you'll quickly create inconsistencies, which are, given the distributed nature, very difficult to get rid of. So store references, not duplicated data.

  • That's correct - in many if not most cases. One however has to think about duplication when response times start to matter. Furthermore sometimes the data may be written ("attached") to or read from a token (e.g. permissions or profiles). The token is signed and verified by each service - which makes the token trust-worthy. And it may carry some information - so one does not necessarily have to query both services, but might be able to map <user_id> to the data in the token. This does not always work though and for those cases I would go with the answer here.
    – Igor
    Jun 25, 2019 at 19:32

It depends on what you're trying to accomplish.

If you want your Reservation API to be self-contained, and you need access to the redundant information, then yes, you'll have to store that information in the Reservation database.

If you're willing to make an API call to the User service to get that information, or look up that information in the User database directly, then no, you don't need to store the redundant information in the Reservation database.

The tradeoff is the usual one: speed vs. Single Source of Truth. Because the performance goal of microservices is scalability (and not necessarily raw execution speed), it shouldn't bother you all that much to go to the single source for the data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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