Skip to content

Azure Service Bus

Overview

Azure Service Bus is a fully managed enterprise message broker that enables reliable, asynchronous communication between decoupled services via messages.

It provides queue-based and publish/subscribe messaging models and is ideal for distributed systems, microservices, or any architecture that requires durable, ordered, and secure communication.

Core Concepts

Concept Description
Queue One-to-one communication. A message is received by a single consumer.
Topic One-to-many (pub/sub). A message is sent to a topic and delivered to all subscriptions.
Subscription A named receiver of a topic's messages; can have filters and actions.
Message A unit of data (payload + metadata).
Dead-letter queue (DLQ) Stores undeliverable or poisoned messages for inspection.
Sessions Maintain order for related messages in a queue (FIFO).
Transactions Group multiple operations into a single atomic unit.

Advantages

  • Decouples services – Senders and receivers don’t need to be online at the same time.
  • Reliable – Guaranteed delivery with retries and dead-lettering.
  • Durable – Messages are stored until processed (via message retention).
  • Ordered delivery – Session support enables FIFO patterns.
  • Advanced messaging patterns – Delayed messages, transactions, scheduled delivery.
  • Security – Role-based access via Azure AD, encryption at rest.

Drawbacks / Considerations

  • Pricing – Premium tier is costly but required for large-scale or low-latency workloads.
  • Operational overhead – Monitoring and dead-letter processing are essential for reliability.
  • Not real-time – Good for near-real-time, but not suitable for ultra-low-latency cases.
  • Message size – Max message size is 256 KB (Standard), 1 MB (Premium).

Example: Queue-Based Communication (C#)

1. Sender – API or service that pushes a message

var client = new ServiceBusClient("<connection_string>");
var sender = client.CreateSender("orderqueue");

var message = new ServiceBusMessage("Order ID 12345");
await sender.SendMessageAsync(message);

2. Receiver – Background service or function that processes the message

var processor = client.CreateProcessor("orderqueue");

processor.ProcessMessageAsync += async args =>
{
    string body = args.Message.Body.ToString();
    Console.WriteLine($"Received: {body}");
    await args.CompleteMessageAsync(args.Message);
};

Use Cases

Scenario Use Service Bus When…
Microservices Services need to communicate reliably without being coupled
Order Processing Pipelines You want to queue tasks for background handling
Scheduled or Delayed Work You need to defer message delivery until a specific time
Message Fan-out (Pub/Sub) One system notifies multiple systems (via topics)
Guaranteed Delivery Message loss is unacceptable
Command/Query separation (CQRS) Separate command processing from API requests

Service Bus vs Alternatives

Feature Service Bus Storage Queues Event Grid
Message durability Yes Yes No (1-24h retention only)
FIFO support With sessions No No
Pub/sub Topics/subscriptions No Yes
Advanced filtering SQL-like filters No Event filtering
Order guarantees Yes (sessions) No No

Security

  • Connection strings with SAS tokens
  • Azure AD RBAC support
  • Private endpoints & firewall rules
  • Encryption at rest

Monitoring & Diagnostics

  • Metrics via Azure Monitor (e.g., active messages, dead-lettered messages)
  • Message tracing and failure analysis
  • Azure Application Insights integration

Conceptual Model

Think of Azure Service Bus as a postal service for your apps:

  • A sender puts a message (letter) in the mailbox (queue/topic)
  • The receiver picks it up when they’re ready
  • You can track undelivered messages (dead letters), ensure order, and even send delayed mail (scheduled messages)

Further Reading