[sethammons]

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.

[orsol]

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.

[sethammons]

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.

[orsol]

Nice, thanks for sharing. Looks like direct communication prevails in your case.