Azure Service Bus

About Azure Service Bus

Azure Service Bus is Microsoft Azure's fully managed enterprise message broker for reliable asynchronous communication between applications and services. It provides durable queues for point-to-point work distribution and topics with subscriptions for publish and subscribe patterns. Service Bus is designed for workloads that need message buffering, transactions, ordered processing, duplicate detection, dead-letter handling, and decoupling between producers and consumers. Buyers should choose the tier and messaging pattern based on delivery semantics, throughput, message size, network isolation, protocol support, and whether enterprise features such as sessions, transactions, or geo-replication are required.

What is Azure Service Bus used for?

Azure Service Bus is used when applications need to exchange work reliably without requiring the sender and receiver to be online or processing at the same speed. Typical scenarios include order processing, background jobs, integration between business systems, command delivery, workflow coordination, load leveling, and communication between cloud and on-premises services.

The broker stores messages durably until consumers can process them, which helps separate application components and smooth traffic spikes. This differs from directly calling another service over HTTP, where both sides normally need to be available at the same time. Service Bus is strongest when the message represents work, a command, or business state that should not disappear because a downstream service is temporarily unavailable.

When should you use queues instead of topics and subscriptions?

Service Bus queues implement point-to-point messaging. A message is placed on a queue and one competing consumer processes that message. This is useful for task distribution, background processing, and load leveling because several workers can share the same queue without each worker receiving every message.

Topics and subscriptions implement publish and subscribe messaging. A publisher sends a message to a topic, and each matching subscription receives its own copy. Subscription filters let different consumers receive selected messages rather than every message published to the topic. Topics are better for one-to-many integration, fan-out, and business events that several independent systems need to process.

How do Basic, Standard and Premium tiers differ?

Microsoft currently offers Basic, Standard, and Premium Service Bus tiers. Basic supports queues but does not provide topics and subscriptions, transactions, duplicate detection, or sessions. Standard adds those enterprise messaging features on shared infrastructure. Premium provides dedicated messaging units for workload isolation, more predictable throughput and latency, virtual network integration, Private Link, geo-replication, and JMS 2.0 support.

Message size is another important difference. Microsoft's current quotas list 256 KB messages for Basic and Standard. Premium can support a single AMQP message up to 100 MB when the entity is configured for large messages. The default Premium maximum is 1 MB per entity, and batch size remains limited to 1 MB. Buyers should select a tier from feature, isolation, and workload requirements rather than treating Premium only as a faster Standard tier.

What current Service Bus limits matter when sizing a namespace?

Microsoft's current Service Bus quotas list 1,000 operations per second for Basic and Standard namespaces. Premium does not publish one fixed operations-per-second ceiling because throughput varies with messaging units and workload characteristics.

Queue or topic size can be configured up to 80 GB. Basic and Standard need partitioning for entity sizes above 5 GB, while Premium supports 80 GB natively. Total namespace storage is limited to 400 GB for Basic and Standard. Premium provides 1 TB per messaging unit. Premium namespaces can use 1, 2, or 4 partitions, selected when the namespace is created, and the partition count cannot be changed afterward. Messaging units must be a multiple of the partition count.

A topic can have up to 2,000 subscriptions. Large messages also consume capacity differently: Microsoft notes that a message above 1 MB sent to a queue counts twice toward entity size, while a large message sent to a topic is counted once for the topic plus once for each matching subscription. These rules make realistic message-size and subscription modeling important before production.

How do delivery guarantees, duplicate detection and sessions work?

Service Bus supports different receive modes with different failure tradeoffs. Peek Lock provides at-least-once delivery: the receiver locks the message and removes it only after successful settlement. If processing fails before completion, the message can be delivered again. Receive and Delete provides at-most-once delivery because the message is removed as it is received, which can lose work if the consumer fails afterward.

Applications using Peek Lock should make processing idempotent because duplicate delivery remains possible. Standard and Premium can also enable duplicate detection to discard repeated sends with the same message identifier inside the configured history window. Sessions provide ordered processing for related messages and are useful when FIFO behavior must be maintained for a business key such as an order or customer workflow.

What must customers migrate before September 30, 2026?

Microsoft is retiring the legacy Azure Service Bus SDK libraries WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, and com.microsoft.azure.servicebus on September 30, 2026. Microsoft is also ending support for the Service Bus Messaging Protocol, or SBMP, on the same date.

Organizations still using these libraries or SBMP should migrate to the current Azure SDK libraries and AMQP before the deadline. Microsoft states that older libraries may still exist after retirement, but they will no longer receive official support and updates. The protocol retirement is more important operationally because applications that still depend on SBMP should not be assumed to continue working after September 30, 2026.

Teams should inventory client libraries, connection transport settings, framework dependencies, and integration products now. Migration testing should include message settlement, serialization, sessions, transactions, retry behavior, and failover because old and current SDKs can differ in defaults and API shape.

What operational features matter in production?

Production designs should plan for dead-letter queues, retries, expiration, monitoring, and capacity. Service Bus automatically maintains a dead-letter queue for each queue and subscription so messages that cannot be delivered or processed normally can be inspected instead of blocking healthy traffic. Dead-letter counts should be treated as an operational signal rather than as permanent storage.

Capacity also needs testing rather than guesswork. Premium namespaces scale with messaging units and can be partitioned for additional capacity, while Standard and Basic use shared infrastructure. Teams should test realistic message rates, message sizes, batch sizes, concurrent receivers, lock durations, and downstream failure scenarios. Monitoring should include active messages, dead-letter messages, throttling, server errors, and processing latency so capacity problems are visible before they become user-facing incidents.

How does Azure Service Bus pricing work?

Azure Service Bus does not have one universal monthly price. Basic charges by messaging operations. Standard combines a base charge with operation-based billing and includes a quantity of operations before additional operation charges apply. Premium is billed by dedicated messaging units, with message operations included within purchased capacity rather than priced per operation.

Microsoft's current pricing page says the first 13 million Standard tier operations per month are included. Premium geo-replication can add replicated data-transfer charges, and partitioned Premium namespaces multiply the messaging unit requirement by the number of partitions. Basic and Standard meter larger messages in 64 KB increments for operation billing. Pricing was checked against Microsoft's Service Bus pricing page on September 4, 2026. Buyers should model volume, message size, connection count, replication, and Premium capacity rather than estimating cost from queue count alone.

How does Service Bus compare with Event Hubs and Event Grid?

Service Bus is designed for reliable brokered messaging where applications need queues, ordered processing, transactions, duplicate detection, dead-lettering, or durable command delivery. Azure Event Hubs is designed for high-volume event streaming and telemetry ingestion, where consumers read ordered streams through partitions and can replay retained events. Azure Event Grid is designed for event notification and routing, where publishers emit events and subscribers react to them with near-real-time delivery.

These services can be used together. Buyers should start with the communication requirement: commands and reliable work queues usually point toward Service Bus, telemetry streams toward Event Hubs, and lightweight event notification toward Event Grid.

Who should choose something else?

Teams that primarily need to ingest large telemetry streams for analytics should compare Azure Event Hubs. Applications that only need lightweight event notification or reactive routing between services may find Azure Event Grid simpler. A storage-backed queue can also be sufficient for simple asynchronous work where enterprise messaging features such as transactions, topics, sessions, and duplicate detection are not required.

Azure Service Bus is strongest when applications need durable business messaging, load leveling, queues or publish and subscribe, and controls for reliable distributed processing. Buyers should choose it because they need brokered messaging semantics and operational controls, not simply because two services need to exchange data.