Log in
TL;DR: Blast radius means how much unrelated traffic is affected when one messaging resource reaches a limit or stops making progress. If every event type shares one Azure Service Bus topic, a backed-up event stream can consume the shared topic budget and affect unrelated publishers. Splitting event streams across topics can make those failures easier to understand and contain.
This post is part of a short series on Azure Service Bus topology under load. The earlier posts explain subscription filters and contention on a shared topic. The series then turns to blast radius and migration strategy. This one looks at how topology choices define failure boundaries.
Most discussions about message broker topology start with throughput. That makes sense because throughput problems are visible and expensive. The same topology also determines how far a failure can spread.
Azure Service Bus makes this especially concrete because topics have size limits. A topic is an Azure Service Bus entity that stores published messages for its subscriptions. Once the topic reaches its maximum size, publishers cannot keep adding messages to it. If that topic carries every event type in the system, the failure boundary is the whole pub/sub path.
Quotas define failure boundaries
Azure Service Bus has documented quotas and limits for topics, queues, subscriptions, filters, forwarding, message size, namespace size, and entity count. Those numbers look like deployment limits: how many entities can I create, how large can an entity become, and when will an API call fail?
For architecture work, I find it more useful to read quotas as failure boundaries. If one entity fills up, what part of the system stops? If one subscription falls behind, how much unrelated traffic shares the same constrained resource?
Capacity is only one question. Also ask which workflows are coupled together by the topic.
The shared-topic failure mode
Imagine a system where all events are published to a shared topic. It carries rare events next to high-volume streams, events with many subscribers, and the occasional slow subscriber that falls behind.
If stored messages accumulate in that topic, the topic quota becomes a shared budget. A burst in one event stream can reduce headroom for every other event stream. A slow path can make an unrelated publisher fail because both flows meet at the same topic.
The exact size budget depends on the tier and entity configuration, so check the current quotas page before relying on a number. The entity that stores the messages defines where pressure accumulates. If many unrelated event streams share one topic, they also share that topic’s storage headroom.
A shared topic can be a reasonable design when the workload is modest, the topology needs to stay small, or compatibility constraints matter. It concentrates failure, so choose that boundary deliberately.
There is another case where a shared topic can be a deliberate design choice: tenant or environment isolation inside a Premium namespace. If several tenants share the same namespace for cost, operational, or deployment reasons, a shared topic per tenant can create a useful pub/sub boundary. The topology still concentrates pressure within that tenant boundary, but that may be exactly the boundary the system wants.
The event-topic failure mode
Now imagine a topology where each event type has its own topic. A high-volume event has its own quota, subscriptions, metrics, and topic depth. A rare event has another. If one event stream backs up, the pressure is visible on that event’s topic.
This topology narrows the failure. A full topic still blocks publishing for that event type, subscribers can still fall behind, and deployment automation has more entities to manage. The affected area is easier to identify and reason about.
| Question | Shared topic | Topic per event type |
|---|---|---|
| Where does topic depth show up? | One combined number for many event streams | One number per event stream |
| What happens when one stream fills the topic? | Unrelated event streams can be affected | The affected event stream is more isolated |
| What is easier to operate? | Fewer entities | Clearer failure localization |
Observability improves when names carry meaning
There is another benefit that is easy to underestimate: entity names become diagnostics. If the topic named after Billing.InvoiceIssued is growing, the investigation starts with billing invoices. If a shared topic called events is growing, the first question is, “Which event type is causing this?”
That matters beyond convenience in the Azure portal. Alerts and dashboards carry more context, and on-call conversations start closer to the problem. A focused topic gives the operator a clue before they open the message payload or query application logs.
When something goes wrong at 2 AM, a descriptive topic name can save the operator from first having to work out which event stream is in trouble.
Entity count is only part of the cost
When teams first see topic-per-event-type, they often worry about cost. That concern is fair. More entities sound like more expense. With Azure Service Bus Premium, however, the main cost unit is the Messaging Unit, not each individual topic. The quotas page allows up to 1,000 topics or queues per Messaging Unit and up to 16,000 per namespace. Entity count still affects deployment and management, but it is not necessarily the same as adding compute instances.
That ceiling is the trade-off that comes with topic-per-event-type. Each event stream becomes its own entity, so the entity count grows with the number of event types. Past 1,000 topics or queues per Messaging Unit, the namespace needs more Messaging Units and that adds cost. Most workloads stay well below the limit, but large event-driven systems should treat the entity budget as part of the cost discussion.
Resource efficiency matters more than entity count alone. If a topology with fewer filters and less shared contention uses less CPU and memory, it may leave more capacity inside the same Messaging Unit. If it makes failures easier to isolate, it may reduce operational cost during incidents.
Entity count alone is a poor comparison. Templates expose the number of entities; load tests expose the runtime work. The design has to account for both.
Choose the failure boundary
A topic is also a failure boundary. Sharing one topic concentrates risk while keeping deployment simple. Topics per event type distribute that risk and make individual event streams easier to observe. The better choice depends on the workload and the failure boundary you want.
For small systems, the simplicity of one topic can be a good trade. For larger pub/sub systems with high event volume, many subscribers, or strict operational expectations, I would want topic size and topic depth to be part of the design discussion from the beginning.
Further reading:
- Azure Service Bus quotas
- Azure Service Bus Premium Messaging
- Azure Service Bus monitoring data reference
- Azure Service Bus throttling
- Previous post: One topic, many subscriptions
- Next post: Incremental topology migration
Common questions
Before changing failure boundaries in an Azure Service Bus system, I would start with these questions.
Does topic-per-event-type remove the risk of a full topic?
No. It narrows the affected area. A full topic is still a production problem, but it is easier to identify which event stream is involved.
Is a shared topic always risky?
Every topology has risk. A shared topic may be a good trade-off when throughput is modest and operational simplicity matters most. The risk becomes more important as unrelated workflows share the same constrained entity.
What should I remember?
Design topics as failure boundaries as well as routing containers.
