# PART 5: MESSAGING & INTEGRATION SERVICES

---

## 5.1 Azure Service Bus

### Overview
Enterprise message broker. Queues and Topics with pub/sub. Reliable, ordered, transactional messaging.

### Entities
- **Queue** — Point-to-point. One sender, one receiver. FIFO (with sessions).
- **Topic** — Pub/sub. One sender, multiple subscribers. Each subscriber gets a copy.
- **Subscription** — Receiver for a topic. Can have filters/rules.

### Key Features
- **Sessions** — FIFO ordering. Messages with same session ID processed in order by one consumer.
- **Dead-Letter Queue (DLQ)** — Messages that can't be processed or expired go here for inspection.
- **Scheduled Messages** — Deliver at a future time.
- **Deferred Messages** — Set aside for later processing.
- **Transactions** — Atomic send + complete across entities.
- **Duplicate Detection** — Discard duplicate messages (based on message ID).
- **Auto-forwarding** — Chain queues/topics.
- **Batching** — Server-side batch for throughput.

### Tiers
| Tier | Features |
|---|---|
| **Basic** | Queues only, no sessions/topics, smaller limits |
| **Standard** | Topics, sessions, 80 GB per entity, pay-per-use |
| **Premium** — Isolated resources, larger limits, no throttling |

### Interview Q&A
**Q: Service Bus Queue vs Storage Queue?**
A: Service Bus = enterprise features (sessions, DLQ, transactions, FIFO, topics). Storage Queue = simpler, cheaper, massive scale, at-least-once delivery. Use Service Bus for complex messaging; Storage Queue for simple, high-volume.

**Q: Queue vs Topic?**
A: Queue = one consumer, point-to-point. Topic = multiple subscribers (pub/sub). Use Topic when multiple systems need the same message.

---

## 5.2 Azure Event Grid

### Overview
Event routing service. Reactive, pub/sub. Route events from Azure services or custom sources to handlers.

### Key Concepts
- **Event Sources** — Where events come from: Blob Storage, Resource Groups, Event Hubs, Service Bus, custom topics
- **Event Handlers** — Where events go: Functions, Logic Apps, Webhooks, Service Bus, Event Hubs, Storage Queues
- **Topics** — Endpoint where sources send events. System topics (Azure resources) or custom topics.
- **Event Subscriptions** — Route events from topic to handler. Filter by subject, event type.
- **Dead-Lettering** — Undeliverable events go to Storage Account or Service Bus.

### Key Features
- Near-real-time delivery (sub-second)
- At-least-once delivery
- Filter events (subject prefix/suffix, event type)
- 10M events/sec per topic (custom topics)
- Serverless — pay per event

### Interview Q&A
**Q: Event Grid vs Event Hubs vs Service Bus?**
A: Event Grid = reactive event routing (fire-and-forget), discrete events (state changed). Event Hubs = big data streaming, high-throughput event stream (telemetry, logs). Service Bus = enterprise messaging with transactions, ordering, sessions (command messages).

---

## 5.3 Azure Event Hubs

### Overview
Big data streaming platform. Ingest millions of events per second. Kafka-compatible.

### Key Concepts
- **Event Hub** — Named stream (like a Kafka topic)
- **Partition** — Ordered sequence of events. Parallelism unit. More partitions = more throughput.
- **Consumer Group** — View of the event hub. Each consumer reads independently.
- **Capture** — Auto-save stream to ADLS Gen2 or Blob Storage (avro format).
- **Partition Key** — Ensures ordering for related events (same key → same partition).

### Key Features
- Up to 7 MB/sec per partition (Standard), 10+ MB/sec (Premium/Dedicated)
- Up to 32 partitions (Standard), 1024 (Premium/Dedicated)
- **Kafka compatibility** — Use Kafka clients directly (no code change)
- Auto-inflate partitions
- Long retention (up to 90 days on Premium/Dedicated)
- **Event Hubs for Apache Kafka** — Endpoint compatible with Kafka 1.0+

### Tiers
| Tier | Partitions | Retention | Throughput |
|---|---|---|---|
| **Basic** | 1 | 1 day | Limited |
| **Standard** | 32 | 7 days | Moderate |
| **Premium** | 1024 | 90 days | High |
| **Dedicated** | Custom | 90 days | Max |

### Interview Q&A
**Q: When to use Event Hubs vs Service Bus?**
A: Event Hubs = high-throughput telemetry/streaming (IoT, clickstream, logs). Service Bus = command messages with business logic, transactions, ordering. Event Hubs for firehose of events; Service Bus for reliable message delivery.

---

## 5.4 Azure API Management (APIM)

### Overview
Publish, secure, transform, analyze APIs. Gateway + Developer Portal + Management plane.

### Components
- **API Gateway** — Proxy. Enforces policies (rate limit, auth, transformation), caches responses.
- **Developer Portal** — Self-service API discovery, documentation (Swagger/OpenAPI), try-it console.
- **Management Plane** — Define APIs, policies, products, developer accounts.

### Key Features
- **Policies** — XML-based rules applied to requests/responses. Inbound, outbound, backend, on-error.
  - Rate limiting, quotas
  - JWT validation, OAuth2
  - Caching
  - Request/response transformation
  - CORS
  - Call other APIs (send-request)
- **Products** — Group APIs. Open (no subscription needed) or Require subscription.
- **Subscriptions** — Developers subscribe to products. API key per subscription.
- **Backends** — Multiple backend types (HTTP, App Service, Function, Service Fabric)
- **API Versions & Revisions** — Version APIs (v1, v2). Revisions for non-breaking changes.
- **Self-hosted Gateway** — Run gateway in your own environment (on-prem, other clouds).
- **WebSocket APIs** — Supported.

### Tiers
| Tier | Use Case |
|---|---|
| **Consumption** | Serverless, pay per API call |
| **Developer** | Dev/test, no SLA |
| **Basic** | Small production |
| **Standard** | Production |
| **Premium** | Multi-region, VNet, self-hosted gateway |
| **Standard v2 / Premium v2** | Newer, improved performance |

### Interview Q&A
**Q: How do you secure APIs with APIM?**
A: Validate JWT tokens, OAuth2/OpenID Connect, subscription keys, rate limiting policies, IP filtering, client certificate authentication. Layer security: subscription key (who) + JWT (what they can access) + rate limit (how much).

---

## 5.5 Azure Logic Apps

### Overview
Workflow automation with visual designer. 200+ connectors. No-code/low-code.

### Key Features
- **Connectors** — Pre-built integrations: Office 365, Salesforce, Twitter, SQL, Storage, etc.
- **Triggers** — What starts the workflow: recurrence, HTTP, event, new email, etc.
- **Actions** — Steps in the workflow: send email, insert row, call API, etc.
- **Conditions, Loops, Switch** — Control flow
- **Error Handling** — Run after configuration (on success, failure, timeout)
- **Integration Account** — B2B scenarios (AS2, X12, EDIFACT, RosettaNet). XML validation, transforms.
- **Stateful vs Stateless** — Stateful = history retained. Stateless = no history, faster.

### Consumption vs Standard
| Feature | Consumption | Standard |
|---|---|---|
| Pricing | Per execution | Fixed + per execution |
| Performance | Shared infrastructure | Dedicated (App Service) |
| VNet | No | Yes |
| Connectors | All built-in + managed | All + custom (code) |

### Interview Q&A
**Q: Logic Apps vs Functions?**
A: Logic Apps = visual, no-code, integration-focused, 200+ connectors. Functions = code-first, compute-heavy, performance-sensitive. Use Logic Apps for orchestration/integration; Functions for complex logic.
