Understand Message Queue, Service Bus and Event Hub

1 min read

Understanding Cloud Messaging: Queue vs. Service Bus vs. Event Hub

In modern applications, services need to talk to each other. But if you have your Order API call your Email Service directly, what happens if the Email Service is down? The Order API fails. This is called 'tight coupling'.

Messaging services solve this. They act as a 'middle-man' to decouple your services. The Order API just drops a 'SendEmail' message into a 'box', and the Email Service picks it up when it's ready. The Order API doesn't even know or care if the Email Service exists.

But not all 'boxes' are the same. The three main types you'll hear about are Queues, Service Buses, and Event Hubs. Choosing the wrong one can be a disaster.

Here's the super-simple analogy we'll use in this cluster:

  • Message Queue: A Post Office Box. It holds mail for one recipient.
  • Service Bus (Topic): A Magazine Subscription Service. One publisher sends out a magazine, and multiple subscribers (Billing, Shipping, etc.) each get their own copy.
  • Event Hub: A Live TV Broadcast / River of Data. It's a massive, high-speed stream of data (like an IoT feed) that many people can 'tune into' and watch at the same time. The data is a continuous log.

This cluster will break down when and why you use each one.

What is a Message Queue? (Simple Decoupling)

Interview Question: 'When would you use a simple Message Queue?'

Answer: 'You use a Message Queue for simple decoupling and load leveling. It's built for a 1-to-1 relationship, where one sender is talking to one logical receiver.'

Analogy: The Post Office Box

You (the Order API) send a letter ('Send welcome email') to the post office box for the EmailService. You don't know or care when the email service checks its mail. You just drop off the letter and leave. This is 'asynchronous'.

Key Pattern: 'Competing Consumers'

The 'receiver' (EmailService) might be a single app. But to be scalable, you might run 10 instances of the EmailService. All 10 instances 'compete' to grab the next message from the single queue. This ensures each message is processed only once by the next available consumer.


Code Example: Sending a message

The sender just needs to know the name of the queue.

// 1. The 'OrderService' (Sender)
// (This is conceptual C# code for Azure Queue Storage)
QueueClient queueClient = new QueueClient(connectionString, "welcome-emails");

// 2. Create the message
string message = "{\"email\":\"[email protected]\",\"name\":\"Test User\"}";

// 3. Drop it in the 'box' and walk away.
// The OrderService's job is done in milliseconds.
await queueClient.SendMessageAsync(message);

// --- Later, on a different server --- 

// 4. The 'EmailService' (Receiver)
// It's in an infinite loop, always checking the queue.
QueueMessage receivedMessage = await queueClient.ReceiveMessageAsync();

// 5. Process the message...
// ... send the actual email ...

// 6. Delete the message so no one else processes it.
await queueClient.DeleteMessageAsync(receivedMessage.MessageId, receivedMessage.PopReceipt);

When to use it: Background jobs. 'A user signed up, send a welcome email.' 'An order was placed, generate a PDF invoice.' Any task you want to do 'later' without making the user wait.

What is a Service Bus? (Pub/Sub & Topics)

Interview Question: 'A Message Queue sounds good. Why would I need a Service Bus?'

Answer: 'You need a Service Bus when one message needs to be received by multiple different services. A queue only lets one receiver get the message. A Service Bus, using the Publish/Subscribe (Pub/Sub) pattern, lets many receivers get their own copy of the same message.'

Analogy: The Magazine Subscription

A publisher (your OrderService) releases one 'ORDER_CREATED' magazine. It sends this to the 'magazine company' (the Service Bus Topic). The 'Billing' department has a Subscription to this topic. The 'Shipping' department also has a Subscription. The Service Bus 'prints' a copy of the magazine for each subscriber. Both get the message, and neither knows the other exists.


Key Concepts

  • Topic: The 'sender' publishes messages to a Topic.
  • Subscription: The 'receiver' creates a Subscription to that Topic. Each subscription gets its own virtual 'queue'. You can have many subscriptions.
  • Filters: Subscriptions can have rules. The 'Shipping' subscription might have a filter: 'Only give me messages where `OrderType == Physical`'.

Code Example: Pub/Sub

// 1. The 'OrderService' (Publisher)
// It doesn't know about Queues, it knows about Topics.
ServiceBusSender sender = client.CreateSender("order-topic");

string orderMessage = "{\"orderId\": 123, \"type\": \"Physical\"}";

// 2. Publish the 'magazine' (message) to the Topic.
await sender.SendMessageAsync(new ServiceBusMessage(orderMessage));

// --- On the 'ShippingService' (Subscriber 1) --- 
// This processor is listening to the 'shipping-subscription'
ServiceBusProcessor processor = client.CreateProcessor("order-topic", "shipping-subscription");
// ... it receives the message and processes it ...

// --- On the 'BillingService' (Subscriber 2) --- 
// This processor is listening to the 'billing-subscription'
ServiceBusProcessor processor2 = client.CreateProcessor("order-topic", "billing-subscription");
// ... it also receives the same message and processes it ...

When to use it: Complex business events. 'An order was created' (ORDER_CREATED) is the classic example. You need the InventoryService, ShippingService, and NotificationService to all react to this one event.

What is an Event Hub / Kafka? (Data Streaming)

Interview Question: 'So a Service Bus handles many messages. Is an Event Hub just a bigger Service Bus?'

Answer: 'No, they solve a completely different problem. A Service Bus is for messaging (passing business commands), but an Event Hub is for data streaming (ingesting massive-scale telemetry). The key difference is that an Event Hub is a persisted event log. Messages aren't deleted when they're read.'

Analogy: The Live TV Broadcast / River of Data

An Event Hub (or Apache Kafka) is like a river. The data (events) is constantly flowing. You can't 'delete' water from the river. Consumers (your services) can 'tap into' the river and read the data as it flows by. They can 'rewind' and re-read the last 24 hours of data. Multiple services can all read from the same 'river' at their own pace.


Key Concepts

  • Massive Throughput: Designed to ingest millions of events per second.
  • Persisted Log: Events are stored in a time-ordered log (for 1-7 days, typically).
  • Consumers are 'Dumb': The Event Hub doesn't track who has read what. The consumer is responsible for remembering its 'cursor' or 'offset' (i.e., 'where was I in the river?').
  • Not for Transactions: You don't use this for 'Order Created'. You use it for 'User clicked a button'.

Code Example: Sending Telemetry

// 1. The 'IoT Device' (Sender)
EventHubProducerClient producerClient = new EventHubProducerClient(connString, "iot-telemetry");

// 2. Create a 'batch' of events to be efficient
EventDataBatch eventBatch = await producerClient.CreateBatchAsync();

// 3. A device might send 100 readings at once
eventBatch.TryAdd(new EventData("{\"temp\": 72.0, \"deviceId\": \"A1\"}"));
eventBatch.TryAdd(new EventData("{\"temp\": 72.1, \"deviceId\": \"A1\"}"));
eventBatch.TryAdd(new EventData("{\"temp\": 72.2, \"deviceId\": \"A1\"}"));

// 4. Send the whole batch in one go
await producerClient.SendAsync(eventBatch);

// --- On the 'AnalyticsService' (Consumer) --- 
// This consumer 'taps into' the stream and reads it
EventHubConsumerClient consumerClient = new EventHubConsumerClient(...);
await foreach (PartitionEvent partitionEvent in consumerClient.ReadEventsAsync()) {
  // ... process the telemetry data ...
}
// The data is still in the Event Hub, so a different
// 'ArchivingService' can also read the same data.

When to use it: Any time you have massive amounts of data that needs to be ingested fast. IoT sensor data, website clickstreams, application logging, financial tickers.

Interview Cheat Sheet: Queue vs. Service Bus vs. Event Hub

Interview Cheat Sheet: The Final Showdown

This is the quick-reference table to memorize for your interview. It summarizes all the key differences.

FeatureMessage QueueService Bus (Topic)Event Hub / Kafka
Analogy Post Office Box Magazine Subscription Data River / TV Stream
Pattern1-to-1 (Competing Consumers)1-to-N (Publish/Subscribe)N-to-N (Data Streaming)
Core ConceptSimple Decoupling, Task QueuingComplex Business Events, WorkflowsMassive-Scale Telemetry Ingestion
Message StateMessage is deleted on read.Message is deleted on read (from its subscription).Message is NOT deleted on read (persisted log).
ConsumersOne logical receiver (can have multiple instances competing).Multiple different receivers (subscribers).Multiple different receivers (consumer groups) that can re-read the log.
Example Use'Send this welcome email.''Order #123 was created.' (Notify Billing, Shipping, etc.)'10,000 IoT devices are sending temperature data every second.'
The 'Big' IdeaLoad LevelingBusiness OrchestrationBig Data / Analytics

💬