The point of microservices - or as I call them focussed services - is dealing with one topic on one logial service (which could be several physical instances).
The kind of architecture you describe could be put in the following services:
- (Payment ...)
Both services save user data.
From what you write, it is not clear, what "user data" means. If it means something like information correlated to a
user identifier, this would be fine. If you are storing some kind of "user"-object, that would be subject to change. Everything user related would be best kept in the
As you distribute your application, you distribute your
User so to say. Every service has a perspective on what a user is. If you need a summary, you have to aggregate one.
The problem is that the user registers on the authorization service. Therefore, he still needs to be registered at the 2 other services. How should this be done?
It follows an admittedly very simplistic description, but you should get the point:
From what was wirtten above. The job of the
auth-Service is simply to build a single point of trust.
auth service is something like a "box office" offering tickets to enter.
The other services trust valid tickets offered by the
Their only responsibility is, checking the validity of the ticket the visitor has.
There is no need for the single services to know, whether a specific user exists. They only have to trust the ticket. Or to put it in another way: The user has not to be registered at any other service than the
The more interesting question would be, how to distribute the information that a basically valid ticket should get invalidated. But that is another topic.
I recommend for further reading:
Auth as a Service: