I am implementing quora like application in which I have Post(question, answers, comments, likes/dislikes) as one microservice and User details as another microservice. I need user details in the post microservice. I need to relate user details with questions, answers, comments and also likes and dislikes? How can I do this? If I do feign client to get user details then where should I store those details? Entities in post microservice need to have a userId as an attribute.

I am using spring boot and sql database.

  • 1
    Why do you think Users and Posts are different domains? If they are so tightly related to each other, why to separate'em? What are you trying to achieve with this segregation?
    – Laiv
    Mar 9, 2021 at 15:16

2 Answers 2


Two important points about microservices:

  1. While microservice architecture explicitly rejects dependencies in code, therr is still, naturally, dependency in data, usually expressed through opaque identifiers. What yhis means is that a Post entity will, naturally, have a UserId field because that's part of the post's data, but that UserId, which can be a number, string, email address or whatever, is meaningless to the Post Service, just an identifier. When processing the post, a handler will be able to take that identifier and query the User Service for details. This isn't a dependency because the Post service, or any handler, doesn't know anything about the User Service except its address and contract. You can version, update or replace it without affecting the callers or updating them all, as long as there are no breaking changes.

  2. The Post and User services are backend services, but when you're talking about displaying the data, you're talking abiut another service, your user facing front end service. This is a separate service that gets data from the different backend services separately and combines them to create the view you need to display to the user. It's common to have a separate data object here, maybe PostView, or just Post in a different namespace, that is a projection of the data, meaning it's not the canonical source of truth or structure. You can either calculate this object on every request, or cache it in the frontend, being careful not to miss changes to the underlying data in the backend.


I'd suggest implementing a wrapper service around your database, exposing interface for getting user data, persisting user data, authentication, whatever else you might need. Probably you will want to containerize this wrapper and the database separately, keeping in mind that the database should communicate only with the backend (all databases I'm aware of support authentication).

Your Post will communicate with the database via the wrapper and its appropriate endpoints. I'm attaching a simple diagram:

enter image description here

This way you will end up with three containers: one for the Post, one for the database wrapper (the REST API) and one for the database itself. You can put the three into a Kubernetes pod or you can leave them as separate microservices, as you find appropriate.

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.