Cloud Integration Architecture: API Gateway, Service Bus and Event-Driven Patterns

The Integration Spaghetti: What Happens Without Architecture

A mid-market company connects its systems over 5 years without integration architecture. The result: 47 point-to-point integrations. The CRM calls the ERP directly via a custom API. The ERP sends files to the warehouse system via SFTP. The e-commerce platform writes to the CRM database directly. The marketing platform pulls from a shared Excel file that someone updates manually. Each integration was built by a different developer at a different time with different technology — REST APIs, SFTP, database links, file shares, and 3 different message queues. Nobody has a complete map of all integrations. When the ERP vendor releases an update, 12 integrations break. The team spends 4 weeks fixing them — discovering integrations they didn't know existed.

Integration architecture replaces spaghetti with structure: centralized API management, message-based decoupling, event-driven reactivity, and workflow orchestration. Each integration pattern serves specific communication needs. The architecture provides: a map of all integrations (visibility), consistent security and monitoring (governance), and the ability to change any system without breaking its consumers (decoupling).

4 Cloud Integration Patterns

Pattern 1: API Gateway — Centralized API Management

The API Gateway sits between API consumers and API providers — providing a single entry point for all API traffic. Capabilities: routing (direct requests to the correct backend service based on URL path, headers, or content), authentication (validate JWT tokens, API keys, or client certificates before passing requests to backends), rate limiting (prevent any single consumer from overwhelming a backend), transformation (modify request/response formats between consumer expectations and provider formats), caching (serve cached responses for repeated queries — reducing backend load and latency), and analytics (track API usage per consumer, per endpoint, per time period).

Azure API Management provides all these capabilities as a managed service. For organizations exposing APIs to partners or building microservices architectures, API Management is the control plane that makes APIs governable. Deploy internal APIs (accessible only within the VNet), external APIs (accessible to partners and customers), and hybrid APIs (on-premises backends exposed through the cloud gateway).

API Management also serves as the developer portal — partners and internal teams discover available APIs, review documentation, test endpoints, and manage their API keys through a self-service portal. This accelerates integration development from weeks (email the API team, request access, wait for documentation) to hours (browse the portal, get a key, start developing).

Pattern 2: Service Bus — Reliable Messaging

Azure Service Bus provides enterprise messaging with guarantees that HTTP APIs can't: guaranteed delivery (messages persist until the consumer acknowledges processing — no message loss), ordering (FIFO sessions ensure messages are processed in the order they were sent), transactions (send and receive messages atomically — either all succeed or none), and dead-letter queue (messages that fail processing move to a separate queue for investigation, not silent loss).

Use Service Bus when: the consumer might be unavailable (messages queue until the consumer returns), ordering matters (financial transactions, state changes), exactly-once processing is required (no duplicate processing, no missed messages), and the publisher shouldn't know or care about consumers (decoupling). The data integration pattern for enterprise systems uses Service Bus to decouple source systems from target systems — the ERP publishes order events to a topic; multiple consumers (warehouse, CRM, analytics) subscribe independently.

Pattern 3: Event Grid — Reactive Event Routing

Event Grid routes events from sources to handlers with sub-second latency. Unlike Service Bus (persistent messaging with guaranteed delivery), Event Grid is fire-and-forget event routing — the event is delivered once, and the handler processes it. Event Grid excels at: Azure resource events (blob created, VM started, database changed → trigger a function), custom application events (order placed, user registered → route to multiple handlers), and webhook integration (external SaaS events → trigger internal processing).

Event Grid vs. Service Bus: Event Grid for event notification (something happened → react to it). Service Bus for command messaging (do this → guarantee it's done). If the handler failing means the event is lost and that's unacceptable, use Service Bus. If the handler failing means retrying the event or accepting the loss is acceptable, use Event Grid. Most architectures use both: Event Grid for real-time notifications and reactive workflows, Service Bus for critical business messaging where loss is unacceptable.

Pattern 4: Logic Apps — Workflow Integration

Logic Apps provides workflow orchestration with 400+ pre-built connectors — connecting SaaS applications (Salesforce, ServiceNow, SAP), Microsoft services (M365, Dynamics, Power Platform), and custom APIs without writing code. A Logic App workflow can: receive a Salesforce event → enrich with data from SQL → create a record in Dynamics → send a Teams notification → wait for manager approval → update the CRM — all configured visually with no custom code.

Logic Apps is the integration platform for business process orchestration — connecting systems that need workflow logic (conditions, loops, approvals, error handling) rather than simple message passing. For system integration scenarios that involve human approvals, conditional routing, or multi-step processing across SaaS applications, Logic Apps provides the fastest implementation path.

Azure Integration Services: The Unified Platform

Azure Integration Services combines all four patterns into a unified platform: API Management for API governance, Service Bus for messaging, Event Grid for event routing, and Logic Apps for workflow orchestration. The four services work together: Logic Apps calls APIs through API Management (centralized authentication and rate limiting), Service Bus queues trigger Logic Apps workflows (message-driven processing), Event Grid routes Azure resource events to Logic Apps (reactive automation), and API Management exposes Logic Apps workflows as managed APIs (governance for integration endpoints). This unified platform replaces: MuleSoft (API + integration), BizTalk (messaging + orchestration), and custom middleware — with managed services that scale automatically and require no infrastructure management.

Integration Design Principles

Decouple publishers from consumers. The order system publishes "order placed" to Service Bus. It doesn't know or care that the warehouse, CRM, and analytics systems consume the event. Adding a new consumer requires a new subscription — not a change to the publisher. This decoupling means systems can change independently.

Idempotent consumers. Messages may be delivered more than once (network retries, consumer crashes). Consumers must handle duplicates gracefully — processing the same message twice should produce the same result as processing it once. Use business keys for deduplication, upsert patterns for database writes, and idempotency keys for API calls.

Schema contracts. Every integration has a defined message schema — JSON Schema, Avro, or Protobuf. The schema is version-controlled and validated at publish/consume boundaries. Schema changes follow backward-compatibility rules — adding fields is safe, removing or renaming fields requires a new version. Schema validation prevents the "changed a field name and broke 5 consumers" failure.

Observability across integrations. Every message carries a correlation ID that traces the business transaction across all systems it touches. Order #12345 generates messages across 8 systems — the correlation ID connects them into a single traceable flow. When something goes wrong, the correlation ID shows: where the transaction went, which system processed it, where it failed, and what state each system is in.

Integration Monitoring: The Observability Gap

Most integration failures are discovered by business users: "the order didn't come through" or "the report shows yesterday's data." Integration monitoring closes this gap with: message flow monitoring (are messages flowing at expected volume? — a sudden drop indicates a publisher failure; a sudden spike indicates a replay or error), latency tracking (end-to-end latency from publish to consume — is the integration meeting its SLA?), error rate dashboards (per integration, per hour — rising error rates trigger investigation before business impact), and dead-letter queue monitoring (messages in dead-letter queues are failed processing — alert when any DLQ has items, and investigate immediately). Azure Monitor + Application Insights provide the telemetry; custom dashboards in Power BI or Grafana provide the visualization. Every integration should have: a health check endpoint (is it running?), a throughput metric (how many messages per hour?), and an error budget (how many failures per hour are acceptable before alerting?).

Integration Security: API Security, Message Encryption, and Access Control

Integration architecture must secure every communication channel: API Management enforces authentication (OAuth 2.0, client certificates) and authorization (scopes, RBAC) for all API traffic. Service Bus encrypts messages in transit (TLS) and at rest (service-managed keys or customer-managed keys in Key Vault). Event Grid validates webhook endpoints (delivery validation handshake prevents unauthorized subscribers). Logic Apps uses managed identity for all resource access — no connection strings stored in workflow definitions. The security principle: every integration connection is authenticated, every message is encrypted, every access is logged. No exceptions for "internal" integrations — internal systems are compromised more often than external-facing ones.

Go Deeper

Continue building your understanding with these related resources from our consulting practice.