Which message pattern should I use?

Question

I'd like to develop a microservice architecture application that sends text messages from one communication provider to another and I'm just considering changing architecture would be best suited to cope with large workload fluctuations.

A text message is commissioned via a REST api and then sent to Whatsapp, Telegram and via email. So the endpoints that send the messages can not know how fast or how reliable the messages can be delivered to the external providers.

I have only worked with request reply patterns for my microservices so far and wonder if it is worthwhile in this usecase to take special care to keep the services asynchronous and to use publish-subscribe pattern? Do you think it would be a good idea or is it not worth introducing more complexity with a message brocker? Would a hybrid solution be better where only the endpoints that send the messages make use of publish-subscribe? Would be a Event based solution here sufficent?

My publish-subscribe stack: Microservices in Go with NATS streaming and deployed on Kubernetes.

My request reply Stack: Microservices in Go with gRCP and deployed on Kubernetes.

Answer 1

I do not have any experience with Go, but to me one of the key elements of microservices is that they communicate as loosely as possible. Eventing is a way to reduce coupling between the sender and the receiver, because (when implemented properly) the sender doesn't need to know who is listening and the receiver doesn't need to know who send it.

But when one service tells another to do something, that coupling is (partially) back, at least from the perspective of time: the receiver will always have to be up and running, when the sender wants to call the API.

Why is the text message sent? What is the business event that caused the sending?

As an example, I'm going to assume that someone on a website placed an order and you want to confirm that order using Whatsapp, Telegram and email. In this case I would create an event OrderPlaced. You can then create a service that listens to that event and decides to send the Whatsapp, Telegram or mail.

That's the difference between a Command and an Event: an event is always describing something that happened in the past (OrderPlaced). A command is telling another component to do something (SendConfirmation).

Key here, is that you took a responsibility away from the order processing service and isolated it into a separate service. If you want, you can go even further and create three services that listen to that same event: one for Whatsapp, one for Telegram and one for email. This would be the ultimate decoupling. If you want to create a fourth possibility to notify, none of the components have to be changed. You can just deploy a new service. This reduces the risk that your Whatsapp is broken, when you added the fourth notification (or changed Telegram).

Edit: To answer your question: Yes I think it's a good idea to use events. Determining whether or not a confirmation has to be sent is a different responsibility than processing the order, so you should isolate them.

Hope this helps.