Microservices communication

Question

I'm actually studying microservices and I'm facing a problem.

Context

I m developing two microservices :

• User management, Spring Based, with MySQL database
• Planning management, ASP.NET based with SQL Server database. The only access point of this service is an API listing some RESTFUL endpoints like /planning/{day}/{userId} or /planning/{startDate}/{endDate}/{idUser}
• Billing management, Node.Js based with MongoDB.

Problems

1. What can I do to only permit accessing the planning information through the user service without couple the two services ? Knowing that the planning service could be accessed later from somewhere else, but not now.

2. How can I do to access billing information from billing service corresponding to a user from the MySQL database? I know that microservices are not coupled, and this point is killing me, cause it has to be coupled in a way no? Like referencing idUser in a billing? Else, how can I know which billing from my API should I expose? More precisely, how do microservices communicate between them, without to be coupled?

3. How to create authentication without duplicating authentication requests to the authentication service, from other services?

Answer 1

The important thing to recognize here is that, when it comes to implementing user authentication, user authorization, and user session management solutions, there aren't significant conceptual differences between the solutions for micro-service architecture and any other form of distributed systems architecture.

Conceptually, the solution will be an implementation of the Kerberos protocol, with the notion of a "ticket" (or "token" as it is more commonly called today) being passed around to establish the identity of users.

So in your case, your user management service will serve as your backend authentication and authorization server, that all other services need to be aware. Your user management service will be responsible for issuing and verifying user tokens to establish your users' identity and roles.

What can I do to only permit accessing the planning information through the user service without couple the two services?

When a user tries to access your .Net service, your service will have to rely on your user management service to establish the user's identity. In other words, your .Net service will need to know where your user management service is (i.e. its URL). You can utilize tools like etcd or nats to propagate the location of your user management service to the rest of your ecosystem, without coupling your microservices to it.

How can I do to access billing informations from billing service corresponding to a user from the Mysql database?

The simplest solution is to pass in the (single?) key (say user ID) as a query parameter in the URL of the billing service. Of course, your billing service has to be implemented in such a way to expect the key being appended to the URL. If you have additional keys that need to be included (say for example, billing dates, order status etc.), maybe you can utilized something like either memcached or redis to store those information at runtime. Of course, now you have to consider the trade-offs of adding these single-point-of-failure to your ecosystem :-)

How to create authentication without duplicating authentication requests to the authentication service, from other services?

Again, once the user is authenticated, all its identity information can be stored in something like either memcached or redis to avoid repeating the authentication and authorization process.

Answer 2

An alternate approach could be building another microservice that protects access to other services with authentication/authorization. This relates to the API Gateway pattern, additional info here: http://microservices.io/patterns/apigateway.html. Basically you'd have a single entry point to your system, and you could use oauth or json web tokens to handle client auth.

Secure access between microservices could also be achieved using something like additional headers and token on http request (kind of "internal" auth).

In my view, microservices shouldn't have this responsibility because you'd probably have to share/duplicate auth logic across your app.

On another note, sharing IDs as "foreign key" is a good approach to decouple your related data.