Event Driven Architectures in Azure

The three Azure eventing services

A real-world architecture often uses all three in different parts of the same system. An e-commerce platform might use Event Hubs to ingest user clickstream data for analytics, Event Grid to trigger an Azure Function when a new order document is created in Blob Storage, and Service Bus to reliably pass the “process payment” task between the order service and the payment service.

Azure Event Grid: reactive event routing

Event Grid is a serverless event routing service. It receives events from event sources (Azure services like Storage, Cosmos DB, Resource Manager, or your own applications) and routes them to event handlers (Azure Functions, Logic Apps, Service Bus queues, webhooks, or Event Hubs).

Event Grid delivers events via HTTP POST to subscribed handlers. It retries delivery using an exponential backoff schedule for up to 24 hours. Events that cannot be delivered can be dead-lettered to a Storage account.

# Subscribe an Azure Function to blob storage events
# (triggers the function whenever a new file is created in the container)

# First, get the function's webhook endpoint
FUNC_URL=$(az functionapp function show \
  --resource-group rg-eventdriven \
  --name func-processorders \
  --function-name ProcessNewOrder \
  --query "invokeUrlTemplate" \
  --output tsv)

# Create an Event Grid subscription for blob creation events
az eventgrid event-subscription create \
  --name sub-blob-to-function \
  --source-resource-id "/subscriptions/{sub}/resourceGroups/rg-eventdriven/providers/Microsoft.Storage/storageAccounts/mystorageacct" \
  --endpoint-type webhook \
  --endpoint $FUNC_URL \
  --included-event-types Microsoft.Storage.BlobCreated \
  --subject-begins-with "/blobServices/default/containers/orders/"

With this subscription in place, every time a new file lands in the orders/ container of the storage account, Event Grid delivers a notification to the Azure Function. The function processes the file without needing to poll the container.

Azure Service Bus: reliable business messaging

Service Bus is a fully managed message broker designed for enterprise messaging patterns. Unlike Event Hubs (streaming, pull-based, no per-message guarantees) and Event Grid (push delivery, best-effort retry), Service Bus provides:

• At-least-once or exactly-once delivery guarantees
• Dead-letter queue — messages that cannot be processed are moved to a dead-letter sub-queue for investigation
• Message sessions — group messages by session ID to guarantee ordered processing per entity (e.g., all messages for a given order processed in order)
• Message deferral — a receiver can defer a message to process it later while continuing to process other messages
• Duplicate detection — prevents the same message from being processed twice based on a message ID

# Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
import json

connection_string = "Endpoint=sb://sb-ns-mycompany.servicebus.windows.net/;..."
queue_name = "order-processing"

with ServiceBusClient.from_connection_string(connection_string) as client:
    with client.get_queue_sender(queue_name=queue_name) as sender:
        order_message = ServiceBusMessage(
            body=json.dumps({
                "order_id": 1001,
                "customer_id": 42,
                "total": 149.99,
                "items": [{"product_id": "SKU-123", "quantity": 2}]
            }),
            message_id="order-1001",           # for duplicate detection
            session_id="customer-42",           # process all messages for customer 42 in order
            subject="new-order"
        )
        sender.send_messages(order_message)
        print("Order message sent to Service Bus queue")

The Saga pattern for distributed transactions

In a distributed event-driven system, a business operation like “place an order” might span multiple services — inventory, payment, shipping, notifications. A traditional database transaction cannot span service boundaries. The Saga pattern replaces a distributed transaction with a sequence of local transactions, each publishing an event when it completes. If any step fails, compensating events trigger rollbacks in preceding steps.

Order Saga:

1. OrderService receives "PlaceOrder" command
   → Publishes "OrderCreated" event

2. InventoryService consumes "OrderCreated"
   → Reserves items
   → Publishes "InventoryReserved" event
   OR
   → Cannot reserve (out of stock)
   → Publishes "InventoryReservationFailed" event

3a. PaymentService consumes "InventoryReserved"
   → Charges customer
   → Publishes "PaymentProcessed" event
   OR
   → Charge fails
   → Publishes "PaymentFailed" event

3b. If "InventoryReservationFailed" or "PaymentFailed":
   → OrderService consumes failure event
   → Publishes "OrderCancelled" event
   → InventoryService releases reserved items on "OrderCancelled"

4. ShippingService consumes "PaymentProcessed"
   → Creates shipment
   → Publishes "ShipmentCreated" event

5. NotificationService consumes "PaymentProcessed" and "ShipmentCreated"
   → Sends confirmation and tracking emails

In Azure, each step uses a Service Bus topic subscription to receive its triggering event and publishes the outcome event back to Service Bus or Event Grid. Each service manages its own local database transaction, ensuring that its own state is always consistent even if the overall saga is in a partially completed state.

Event sourcing: events as the source of truth

Traditional systems store the current state of data: “customer 42 has a balance of $150.” Event sourcing stores the events that led to that state: “customer 42 deposited $200, then withdrew $50 — balance is $150.” The event log is the source of truth, and current state is derived by replaying the events.

Event Hubs is well-suited as the event store when combined with its Capture feature. All events are stored durably in ADLS Gen2. A new service can replay all historical events to build its own projection of the current state. This is called a projection or read model.

# Simplified event sourcing: rebuild account balance from events
from azure.eventhub import EventHubConsumerClient, EventPosition
import json

def rebuild_account_balances():
    """Replay all events from the beginning to reconstruct current balances"""
    balances = {}

    with EventHubConsumerClient.from_connection_string(
        conn_str="Endpoint=sb://...",
        consumer_group="balance-rebuild-cg",
        eventhub_name="account-events"
    ) as client:

        def process_event(partition_context, event):
            payload = json.loads(event.body_as_str())
            account_id = payload["account_id"]
            event_type = payload["event_type"]
            amount = payload.get("amount", 0)

            if account_id not in balances:
                balances[account_id] = 0

            if event_type == "deposit":
                balances[account_id] += amount
            elif event_type == "withdrawal":
                balances[account_id] -= amount
            elif event_type == "fee":
                balances[account_id] -= amount

        # Read from the earliest available event
        client.receive(
            on_event=process_event,
            starting_position="@latest" if False else "-1",  # -1 = earliest
            max_wait_time=10  # Stop after 10 seconds of no new events
        )

    return balances

current_balances = rebuild_account_balances()
print(f"Rebuilt balances for {len(current_balances)} accounts")

Choosing the right pattern for your use case