Service Bus Topics vs Queues: Which One Do You Actually Need?
Most teams reach for a Service Bus topic because it sounds more flexible. Count workflows, not services: if one workflow consumes the message, a queue is the right call.
The definitions are the easy part, and they are also the part that does not help you decide.
A queue has one logical consumer. Messages go in, each message is delivered to exactly one receiver. You can run twenty instances of your worker against that queue and they will compete for messages, but they are all the same consumer doing the same job. Scaling out is not the same thing as having more than one consumer.
A topic has subscriptions, and each subscription gets its own copy of the message. Three subscriptions means three independent consumers, each working through its own copy on its own schedule, each with its own backlog and its own failures.
That is where most write-ups stop, which is why people pick wrong. Both descriptions sound fine. The real question is not about the entity, it is about what is on the other side.
Count workflows, not services
If one workflow consumes the message, use a queue. That workflow can do as many things as it needs to. Process the message, write an audit record, push a notification, update a projection. That is still one consumer. The steps run inside one handler, in the order you wrote them, with one transaction boundary and one place to catch a failure.
If several unrelated consumers need the same message and none of them care what the others do, use a topic. Billing does not wait on search indexing. Search indexing does not need to know billing exists. Neither one breaks if the other is down for an hour.
The failure mode is splitting one workflow across subscriptions
This is the mistake worth naming, because it looks like good decoupling right up until it isn’t. You have three steps that happen to live in three services, so you give each one a subscription. Now step two needs step one to have finished. Step three needs both.
The order that matters here is the order the services touch the message, not the order the messages arrive. Those are different problems, and only one of them has anything to do with which entity you picked.
You have not decoupled anything. You took an ordered sequence, removed the ordering, and rebuilt it out of retries and hope. Every subscription now has to handle arriving early, and you get to find out which ones don’t at three in the morning.
If the steps depend on each other, they are one workflow. One workflow is one consumer. One consumer is a queue.
One correction, because people repeat this wrong
A queue does not give you message ordering either. Point two receivers at a queue, or one receiver with concurrency above one, and messages come out of order. What a queue gives you is ordering within a single handler, which is usually the ordering you actually wanted. If you need the messages themselves handled in sequence, that is sessions, and sessions work on subscriptions too.
Ordering is not the reason to pick a queue. Having one workflow is.
”We might need another consumer later”
Maybe. A topic with one subscription is a queue with extra indirection, an extra entity to name, and a filter rule nobody remembers writing. You pay that every day for a maybe.
Converting later is not free, but it is contained. Create the topic, repoint the senders, drain the queue, delete it. That is an afternoon. It is a lot cheaper than the dependency graph you invent by splitting a workflow apart on day one.
Count workflows, not services. One workflow, one queue. Independent consumers who do not care about each other, one topic.