I've been working in a related space for a few years and wanted to offer a few counterpoints to the article. First, if you're doing request/response using mess

I've been working in a related space for a few years and wanted to offer a few counterpoints to the article. First, if you're doing request/response using messaging, you're probably doing it wrong. Pub/sub and request/response are totally different animals. I for one, consider it both reasonable and necessary to use both side-by-side, in the same infrastructure. (Is this view uncommon?) In our technology stack, which is a monolith-becoming-microservices, we use both pub/sub and request/response side-by-side. The general rule is that if service A calls service B, if the nature of that interaction is such that service B's response can preempt/interrupt/influence service A, the call needs to be done inline, in service A. If the nature of the interaction is more "advisory", use pub/sub. Examples (from the hotel booking space): (a) When a reservation gets canceled, we publish a cancellation event. The reservation is then CANCELED, officially. A separate service sees the cancellation event and frees the associated held room inventory; that's a pub/sub interaction. (b) When a reservation wants to check in to a room, we check whether the room is already occupied. This has to be done using request/response (in our case, gRPC) because if the room is occupied, that's a hard gate on the success of the checkin. Second, pub/sub != work queues. Pub/sub is about distributing small bits of information all over the system and letting things be advised of stuff. Using a messaging system as a work queue is overall pretty stupid. I know it's common to use a message broker like RabbitMQ for task distribution, but it's silly. It's really silly when the tasks themselves contain huge binary objects inline, as part of the message payload. Store that shit in S3 or a proper system, and keep the message payloads light. I guess that's all for now.