CODEWITHSUNDEEP
asynchronousspring-cloudsynchronousmicroservicesmessagebroker
user1675642
user1675642

Reputation: 777

How should a synchronous public api be integrated with message-based services?

I've been reading about microservices, and have found a lot of interesting advice in Jonas Bonér's Reactive Microservices Architecture (available to download free here). He emphasises the need for asynchronous communication between miroservices, but says that APIs for external clients sometimes need to be synchronous (often REST).

I've been trying to think how asynchronous response messages sent back from microservices should best be routed back to the waiting client. To me the most obvious way would be to record something like a request id in all messages sent when processing the request, and then copy this id into response messages sent by the services. The public API would block when processing the request, collecting all expected response messages which have the matching id, before finally sending the response to the client.

Am I on the right lines here? Are there better approaches? Do any frameworks take the work of doing this routing away from the developer (I'm looking at Spring Cloud Streams etc, but others would be interesting too)?

Upvotes: 2

Views: 488

Answers (1)

Sean Farmar
Sean Farmar

Reputation: 2293

He emphasises the need for asynchronous communication between miroservices, but says that APIs for external clients sometimes need to be synchronous (often REST).

When dealing with client - backend communications you can have a couple of types of operations and they should be handled seperetly (look at the idea of CQS):

  • State changing operations - they should be one way fire and forget using messaging (it can be the client calling an HTTP API and the api dispatching the message)

  • read operations: synchronous (request response) operations (using an HTTP API) and this is does not involve any messaging what so ever

Does that make sense?

Upvotes: 1

Related Questions