loading...

re: Microservices communications. Why you should switch to message queues. VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I'm specifically talking about service architecture, and not background jobs. I recognize that the two are only tangentially related. Definitely no...

Here's my understanding: microservices have smart endpoint and dumb pipes. So it's the service's responsibility to account for message redeliveries like you already pointed out.

One way out would be to make the message processing operation idempotent. Two cases here:

  1. The operation is idempotent in and of itself. Doing nothing here will cause no side-effects.
  2. The operation is not idempotent in nature. Use an identifier (eg. a random unique guid, or hash of the message, etc.) to ensure a message is processed once per request.

Your thoughts?

Indeed. However, a unique message identifier would have to be persisted in order to know that it has been previously processed. Where possible, and where the messaging tool is homogenous (within a logical service, rather than integrating disparate logical services), then a message sequence number can be a better option (especially in cases where event sourcing is in use).

The message sequence number is interesting, thanks!

code of conduct - report abuse