How to have dependency between two different microservices?

Question

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.

Answer 1

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.

Answer 2

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:

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.