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, transactional messaging, ordered processing, duplicate detection, dead-letter handling and decoupling between producers and consumers. Buyers should choose the tier and messaging pattern based on reliability requirements, expected throughput, message size, network isolation and whether 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 is different 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 itself represents work, a command or business state that should not disappear just 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. Microsoft documents subscription filters so different consumers can receive selected messages rather than every message published to the topic. Topics are therefore 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 and uses operation-based billing with a base charge. 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 limits list 256 KB messages for Basic and Standard. Premium can support single AMQP messages up to 100 MB when the entity is configured for large messages, while HTTP and other protocol limits are lower. Buyers should select a tier from the features and workload profile rather than treating Premium only as a faster version of Standard.

How do delivery guarantees, duplicate detection and sessions work?

Service Bus supports different receive modes with different failure tradeoffs. Microsoft's current reliability guidance says 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 therefore make processing idempotent because duplicate delivery is 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 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. Microsoft recommends monitoring dead-letter counts and treating poison messages as an operational signal that needs investigation.

Capacity limits also matter. Microsoft's current quotas document namespace connection limits, entity-size limits, subscription limits and different namespace capacities by tier. Premium namespaces use messaging units and can be partitioned for additional scale, while Standard and Basic remain shared-capacity services. Teams should test realistic message rates, batch sizes, processing times and failure scenarios before production rather than sizing only from average throughput.

How does Azure Service Bus pricing work?

Azure Service Bus does not have one fixed monthly price. Basic charges by messaging operations. Standard combines a base charge with operation-based billing and includes a quantity of operations and brokered connections before additional charges apply. Premium is billed by dedicated Messaging Units and includes transactions within the purchased capacity rather than charging per message operation.

Premium geo-replication can add data transfer charges, and partitioned Premium namespaces multiply the Messaging Unit requirement by the number of partitions. Microsoft also counts larger messages as multiple billable operations in Basic and Standard because operations are metered in 64 KB increments. Pricing was checked against Microsoft's current Service Bus pricing page on August 25, 2026. Buyers should model message volume, size, connection count, required features and Premium capacity rather than estimating 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 very 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.

Microsoft's current comparison shows that Service Bus supports transactions, duplicate detection and FIFO ordering through sessions, while Event Hubs and Event Grid are optimized for different event patterns. 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 millions of telemetry events per second 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 basic 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 features that help coordinate 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.