Microsoft Azure services
9 / 24
Microsoft Azure

Messaging & Events — Service Bus, Event Grid & Storage Queues

Decouple services with the right Azure messaging service, and be able to say why it is not one of the others.

Azure has four, and the interview is about telling them apart.

Service Bus is a work ticket handed to one person who must sign it off. Event Grid is a tannoy announcement to everyone who asked to hear that kind of news. Event Hubs is a conveyor belt past several stations, with everything staying on it for a while.

Key Concepts

1
    Storage Queues  simple, cheap, huge. No ordering, no topics.
    Service Bus     enterprise broker: FIFO, transactions, topics,
                    sessions, dead-letter. The default for commands.
    Event Grid      push-based event ROUTING, filtered, near-instant.
    Event Hubs      high-volume streaming, replayable. Telemetry.
2
The dividing line is message versus event. A message is a command with an owner — "charge this card", and someone must handle it. An event is a notification — "an order was placed" — and the publisher does not care who listens.
3
Service Bus carries commands.
    producer -> [ queue ] -> one consumer
    producer -> [ topic ] -> subscription A (filter: total > 500)
                          -> subscription B (filter: region = 'IN')
4
Topics give you one publish and several filtered subscribers, which Storage Queues cannot do at all.
5
Peek-lock is the Service Bus equivalent of a visibility timeout.
    receive -> message locked, not deleted
            -> Complete()  removes it
            -> Abandon()   returns it immediately
            -> lock expires -> redelivered
6
So consumers must be idempotent, and MaxDeliveryCount moves a poison message to the dead-letter queue instead of looping forever.
MaxDeliveryCount
7
Sessions give ordering per key. Set a SessionId and all messages for that customer go to one consumer in order, while other sessions process in parallel — the answer to "how do you keep per-customer order without serialising everything".
SessionId
8
Event Grid is push, not pull. It delivers to a webhook, Function or Logic App within seconds, retries with backoff, and filters on event type or subject. It is how you react to "blob created" or "resource deleted" without polling.
9
Event Hubs is the streaming one, partitioned, with consumers tracking their own offset so they can replay. Millions of events per second; it is Azure's Kafka-shaped service and has a Kafka-compatible endpoint.
10
What the interviewer is probing.1. "Service Bus, Event Grid or Event Hubs?" Probing: message versus event versus stream. Stalls: "They all do messaging." Moves up: Service Bus carries commands that must be handled, Event Grid routes notifications to subscribers, Event Hubs ingests high-volume replayable streams.
11
2. "What is peek-lock and what breaks if processing is slow?" Probing: the duplicate cause. Stalls: "It locks the queue." Moves up: the message is locked rather than deleted; if the lock expires before Complete, it is redelivered and processed twice.
12
3. "How do you keep per-customer ordering without serialising everything?" Probing: sessions. Stalls: "Use a FIFO queue." Moves up: Service Bus sessions — messages with the same SessionId go to one consumer in order, while other sessions process in parallel.
13
4. "When would you choose a Storage Queue?" Probing: the simple option. Stalls: "Never." Moves up: when you need a cheap, very large backlog and none of the broker features — no topics, no sessions, no transactions.
Use cases:service-busevent-gridevent-hubspeek-locksessions