Skip to main content

API Management & Messaging Patterns

Learn to design robust APIs and event-driven systems using Azure’s messaging services. Azure Messaging Architecture

What You’ll Learn

By the end of this chapter, you’ll understand:
  • What APIs and messaging are (and why they’re different from direct function calls)
  • How services communicate (sync vs async, when to use each)
  • Azure API Management (protecting and managing your APIs)
  • Service Bus vs Event Hub (and why choosing wrong costs money)
  • Event-driven architectures (Saga pattern, Event Sourcing)
  • Real-world patterns with actual costs and trade-offs

Introduction: What Are APIs and Messaging?

Start Here if You’re Completely New

API = How one application talks to another application Messaging = Sending messages between applications asynchronously Think of it like communication methods: API (Synchronous) = Phone Call
Messaging (Asynchronous) = Text Message

Why This Matters: The Cost of Tight Coupling

Real-World Failure Example

Target Data Breach (2013)
  • Bad Architecture: All systems directly connected (no API gateway, no security layer)
  • What happened: Hackers accessed HVAC system → Used it to access payment system
  • Result: 40 million credit cards stolen
  • Cost: $292 million
  • Prevention: API Gateway with authentication + network segmentation
  • Prevention cost: ~$500,000
  • ROI: 584x return on investment ✅
More Examples: The Pattern: Proper APIs and messaging cost thousands. Tight coupling costs millions.

Synchronous vs Asynchronous Communication (From Scratch)

Let’s understand the fundamental difference:

Synchronous (API Calls) - “Phone Call” Model

When to Use Synchronous:
  • ✅ Need immediate response (user login)
  • ✅ Short operations (<1 second)
  • ✅ User is waiting for result
  • ✅ Simple request/response
When NOT to Use:
  • ❌ Long operations (video encoding, report generation)
  • ❌ External dependencies that might be slow
  • ❌ Operations that can fail frequently

Asynchronous (Messaging) - “Text Message” Model

When to Use Asynchronous:
  • ✅ Long operations (>1 second)
  • ✅ Don’t need immediate response
  • ✅ Need reliability (retries, durability)
  • ✅ High throughput (millions of operations)
  • ✅ Decoupling services (payment fails ≠ order API fails)
Real-World Example: E-commerce checkout

Common Mistake: Using Wrong Communication Method

Mistake #1: Synchronous for Long Operations

The Trap:
The Fix (Asynchronous):
Cost Impact:
  • Synchronous: 90% of uploads fail (timeout) → Lost users
  • Asynchronous: 99.9% success rate → Happy users ✅

Mistake #2: Asynchronous for User Login

The Trap:
The Fix (Synchronous):
Decision Tree: Sync or Async?

Understanding Azure’s Messaging Services (Simplified)

Azure has 3 main messaging services. Here’s how to choose:

The Restaurant Analogy

Azure Service Bus = Restaurant Order Ticket
Use Service Bus When:
  • ✅ Need guaranteed delivery (can’t lose messages)
  • ✅ Need order preservation (FIFO)
  • ✅ Critical business operations (orders, payments)
  • ✅ Need transactional guarantees
Cost: 10/month+10/month + 0.05 per million operations
Azure Event Hub = Security Camera Footage
Use Event Hub When:
  • ✅ Need high throughput (millions of events)
  • ✅ Multiple consumers need same data
  • ✅ Telemetry and logging
  • ✅ OK to lose occasional event (not critical)
Cost: 11/month+11/month + 0.028 per million events
Azure Event Grid = Building Fire Alarm
Use Event Grid When:
  • ✅ React to Azure resource events (blob uploaded, VM created)
  • ✅ Serverless workflows (trigger Azure Functions)
  • ✅ Simple event routing
  • ✅ Need low latency
Cost: $0.60 per million events (cheapest!)

Decision Matrix: Which Service?

The Key Mental Model: Think of the fundamental question each service answers:
  • Service Bus: “Did this message get processed exactly once?” — When you absolutely cannot lose or duplicate a message (payment, order). Service Bus gives you sessions, dead-letter queues, and transactional processing.
  • Event Hub: “What happened recently?” — When you need a firehose of data and multiple systems need to read the same stream independently. Event Hub is an append-only log, like Kafka.
  • Event Grid: “Something just happened, who cares?” — When you need reactive, event-driven automation. Event Grid is the nervous system of Azure — it natively integrates with 30+ Azure services.
Common Pitfall: Using Service Bus for logging/telemetry. Service Bus guarantees delivery and ordering, which sounds good — but at 1 million messages/second, the overhead of those guarantees makes it 10-50x more expensive than Event Hub. For telemetry, you do not need exactly-once processing — if you lose one log line out of a million, nobody notices. Use the simplest (and cheapest) service that meets your actual requirements.

Real-World Cost Example: Choosing Wrong Service

Scenario: IoT application with 1,000 devices sending data every second Option 1: Service Bus (WRONG)
Option 2: Event Hub (CORRECT)
Lesson: Using wrong service costs 70% more + worse performance!
[!TIP] Jargon Alert: API Gateway vs Service Mesh API Gateway (like Azure API Management) sits at the edge and handles external traffic—rate limiting, authentication, versioning. Service Mesh (like Istio) sits between microservices and handles internal traffic—retries, circuit breaking, observability.
[!WARNING] Gotcha: Service Bus vs Event Hub Confusion Choosing wrong can cost you! Service Bus = reliable messaging with FIFO guarantees (order processing). Event Hub = high-throughput streaming for telemetry. Using Service Bus for telemetry = expensive and slow. Using Event Hub for orders = lost data!

1. Azure API Management (APIM)

Azure API Management is a fully managed service to publish, secure, transform, maintain, and monitor APIs.

When to Use APIM

Use APIM For

  • External API exposure
  • Rate limiting and quotas
  • API versioning and monetization
  • Request/response transformation
  • OAuth/JWT validation
  • Developer portal

Don't Use APIM For

  • Internal microservice communication (use Service Mesh)
  • Simple reverse proxy (use App Gateway)
  • Real-time streaming (use Event Hub)
  • High-latency tolerance apps (adds ~50ms)
Cost Warning: APIM Tier Selection Matters Enormously The most common APIM cost mistake is choosing Standard or Premium tier “for production” when a Consumption tier would suffice. If your API handles fewer than 1 million calls/month, Consumption tier costs approximately 3.50/monthcomparedto3.50/month -- compared to 700/month for Standard. That is a 200x price difference. Only upgrade when you genuinely need VNet integration, custom domains with client certificates, or multi-region deployment.

APIM Architecture


2. APIM Core Concepts

API Gateway Policies

Policies are XML configurations that execute on API requests/responses.

API Versioning Strategies

Recommended: Most explicit and discoverable

3. Azure Service Bus

Service Bus is a fully managed enterprise message broker with queues and publish-subscribe topics.

Service Bus vs Event Hub vs Event Grid

The Decision Tree:

Comparison Table


4. Service Bus Patterns

Pattern 1: Queue (Point-to-Point)

Code Example:

Pattern 2: Topic/Subscription (Pub/Sub)

Code Example:

Pattern 3: Request-Reply


5. Azure Event Hub

Event Hub is a big data streaming platform and event ingestion service.

Event Hub Use Cases

Telemetry Ingestion

  • IoT device data
  • Application logs
  • Performance metrics
  • Clickstream data

Real-Time Analytics

  • Live dashboards
  • Anomaly detection
  • Fraud detection
  • Stream processing

Event Sourcing

  • Append-only event log
  • Event replay
  • Audit trail
  • Time travel queries

Data Pipelines

  • ETL workflows
  • Data lake ingestion
  • Cross-region replication
  • Archive to storage

Event Hub Architecture

Code Example:

6. Event-Driven Architecture Patterns

Pattern 1: Saga Pattern (Distributed Transactions)

Problem: How to maintain data consistency across microservices? Solution: Coordinate a sequence of local transactions with compensating actions. Implementation:

Pattern 2: Event Sourcing

Store state as a sequence of events, not snapshots.

7. API Gateway Patterns

Pattern 1: API Aggregation (Backend for Frontend)

Problem: Mobile app needs data from 5 different microservices. Solution: Create a BFF (Backend for Frontend) API that aggregates responses.

Pattern 2: Circuit Breaker in APIM


8. Interview Questions

Beginner Level

Answer:Service Bus Queue (Point-to-point):
  • Single consumer processes each message
  • Order processing, payment processing
  • Competing consumers for scale
Service Bus Topic (Pub/Sub):
  • Multiple subscribers receive each message
  • Notification systems (email, SMS, push)
  • Event broadcasting to multiple services
Example: Order created event → Topic sends to inventory, shipping, and analytics services
Answer:Event Hub:
  • High throughput (millions events/sec)
  • Streaming and telemetry
  • Partition-based ordering
  • No dead letter queue
  • Use: IoT telemetry, logs, clickstream
Service Bus:
  • Reliable messaging (thousands/sec)
  • Transactional guarantees
  • FIFO ordering (with sessions)
  • Dead letter queue for failed messages
  • Use: Critical business transactions

Intermediate Level

Answer:Setup:
  1. Create API version set in APIM
  2. Add multiple API versions (v1, v2)
  3. Choose versioning scheme (URI, query, header)
Example (URI versioning):
Result:
  • /v1/products → Backend API v1
  • /v2/products → Backend API v2
Answer:Architecture:
Code:

Advanced Level

Answer:See Section 6 - Saga Pattern above for complete implementation.Key Points:
  • No distributed 2PC (two-phase commit)
  • Each service has local transaction
  • Compensating actions for rollback
  • Saga coordinator tracks state
  • Eventual consistency
Challenges:
  • Compensating actions must be idempotent
  • What if compensation fails? (Retry with exponential backoff)
  • Partial failures require careful state management
Answer:Tiered Rate Limiting:
Response when limit exceeded:

9. Key Takeaways

Choose the Right Tool

APIM for APIs, Service Bus for messaging, Event Hub for streaming. Don’t use a hammer for a screw.

Decouple Services

Asynchronous messaging prevents cascading failures and enables independent scaling.

Handle Failures Gracefully

Dead letter queues, retries, circuit breakers, and compensating transactions are essential.

Design for Idempotency

Messages can be delivered more than once. Make sure processing is safe to repeat.

Monitor Everything

Track message latency, queue depth, dead letter count, and API response times.

Version Your APIs

Breaking changes require new versions. Use URI versioning for clarity.

Next Steps

Continue to Chapter 17

Master SRE practices, SLIs/SLOs, error budgets, and production excellence