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.