I tend to reach for a queue when an item should processed by a single consumer and you have fancy retry logic.
I tend to reach for a message bus when N consumers may need to know about an event that happened.
I usually start with a synchronous API call to the target service over http and only reach for other methods when reliability, response time, or throughput concerns justify it.
Thanks for the reply. What is the approximate percentage of connections that goes directly from service to service rather than from service to message bus/queue?
I'm curious about the order of magnitude.
Just depends on what can be lost and how you handle retries. Last big service I worked on (throughput of a few billion work items / incoming api requests per day) had a dozen network dependencies. We leveraged an in house queuing system, kafka as a bus, and all calls to other services as direct calls with heavy caching. Every call interacted multiple times with the queue (minimum 2) and sent out ~8 events. Each call leveraged direct network calls to the dependent services but due to caching responses, batching, pre-pulling data to cache, etc we would typically keep calls under a couple thousand requests per second.
So more direct to your question, I guess you could say 1 request became 2 queue calls, 8 bus events, and a dozen direct network calls at 90% cache hit ratio.
I tend to reach for a message bus when N consumers may need to know about an event that happened.
I usually start with a synchronous API call to the target service over http and only reach for other methods when reliability, response time, or throughput concerns justify it.