18

I current using a RPC call to another microservice via TCP and getting the response, but I think I can do it in this way:

whithout make a RPC call, can I use a pub/sub to send to one service, publishing some channel like request_user and subscribed to a channel like object_user_response, and then the other service that is subscribed to this request_user, publish object_user_response.

Like that:

Service A <-- (sub)object_user_response <------  Redis
Service A --> (pub)request_user ------------->   Redis

Service B <-- (sub)request_user <--------------- Redis
Service B --> (pub) object_user_response ------> Redis

On receive a object_user_response, the service A checks if the id of user is the same that the function have requested.

Should I use RPC or Pub/sub for that? What is the most correct way to send data to a microservice and get response from there in terms of loosely coupled architecture, is using a RPC call or using two pub/sub, on for the request and another for the response?

Augusto Will
  • 562
  • 7
  • 20

2 Answers2

29

Actually there's no one answer to this question. It depends :-)

With RPC from one hand you have more tied relation between services but from another hand you have more simple request/response communication model. So, one service sending request expects some kind of response from another or timeout if it isn't accessible. RPC with TCP also has session and bidirectional communication way.

With pub/sub model one service sends some message about some happened event and doesn't care how this message will be handled by another services. Or service sends message to one particular service and doesn't expect response from it - (one-way request). Of course second service may send a message to the first service too passing some work results.

Loosely coupled is not a goal itself - it's a way how to make system more reliable, stable, scalable but it comes with some price, work overheads, in some cases it's impossible or simply is unnecessary.

So, depending of your need you can choose the first or the second approach. The RPC is used when you can't simply send request and forget or it has no sense, you need response anyway. RPC is easier to implement. Pub/sub is good for some kind of "heavy" background jobs like image, video, file processing, sending emails and so on where you send request and it will be processed in queue. With pub/sub you can utilize resources more efficiently.

zthomas.nc
  • 3,689
  • 8
  • 35
  • 49
Vasyl Zvarydchuk
  • 3,789
  • 26
  • 37
6

Depends on your use case and really has nothing to do with "decoupling". If your call from the producing service must wait for a response from a consuming service, then synchronous messaging should be used (RPC). Asynchronous forms of communication like pub/sub are used when the producing service sends a message intended to be consumed by another service and carries on its marry way without waiting for, or even needing a response.

Asynchronous forms of communication are preferable in the microservices world when you can get away with it because blocked threads and waiting for responses is expensive. Good architecture will help decouple run time dependencies between services, so that each operate independently as much as possible without directly relying on other services to do the job it's been assigned.

Gerry Mantha
  • 1,068
  • 7
  • 14