Integration & Application Connectivity

Integration & Application Connectivity

1. API Gateway Patterns

AWS API Gateway acts as the “front door” for your applications. It handles traffic management, authorization, and throttling.

Feature / Pattern REST API HTTP API WebSocket API
Primary Use Case Legacy migrations, enterprise apps requiring deep customization. Microservices, serverless backends (Lambda), cost-sensitive apps. Real-time, bidirectional chat apps, live dashboards, notifications.
Protocol HTTP/1.1 (RESTful) HTTP/1.1 & HTTP/2 (RESTful) WebSocket protocol (ws:// or wss://)
Features Heavyweight: Cache, WAF, client certificates, transformation. Lightweight: Minimalist, fast, JWT/OIDC authorization. Persistent connections, framing, connection management.
Cost & Speed More expensive, higher latency. Up to 70% cheaper and faster than REST APIs. Billed per connection minutes and messages sent.

  • When to choose HTTP over REST: Always default to HTTP APIs for modern serverless apps unless you explicitly need API Gateway caching, edge-optimization, or AWS WAF integration directly on the gateway.

2. EventBridge vs. SNS vs. SQS

These three services form the backbone of AWS asynchronous communication, but they serve entirely different integration needs.

Amazon SQS (Simple Queue Service)

  • Pattern: Point-to-Point (Pull-based). One producer talks to one consumer group.

  • How it works: Messages are stored in a queue until a consumer pulls them, processes them, and deletes them.

  • Best for: Decoupling microservices, smoothing out traffic spikes (buffering), and ensuring work isn’t lost if a backend goes down.

Amazon SNS (Simple Notification Service)

  • Pattern: Pub/Sub (Push-based). One producer talks to many consumers simultaneously.

  • How it works: A producer sends a message to an SNS Topic, and SNS immediately pushes that message to all subscribed endpoints (Lambda, SQS, HTTP, Email).

  • Best for: High-throughput fan-out scenarios where you need to trigger multiple unrelated systems instantly.

Amazon EventBridge

  • Pattern: Event Bus (Pub/Sub with advanced routing). * How it works: It acts as a central nervous system. It accepts events from your apps, AWS services, or SaaS partners (like Stripe or Zendesk) and routes them based on JSON rules.

  • Best for: Building complex, decoupled Event-Driven Architectures where schemas matter and you need to route events based on payload content.

3. Step Functions: Orchestration vs. Choreography

When building microservices, you need to coordinate how tasks are executed.

Orchestration (AWS Step Functions)

Think of an orchestrator as a conductor of an orchestra.

  • How it works: A centralized service (Step Functions) explicitly tells every microservice what to do, when to do it, and handles errors if they fail.

  • Pros: Highly visible state, easy to debug, handles complex conditional logic ($if/then$), built-in retries.

  • Cons: Central point of failure/tight coupling to the state machine.

Choreography (Event-Driven)

Think of choreography as a ballet dance.

  • How it works: There is no central manager. Services react blindly to events using tools like EventBridge or SNS. Service A finishes and fires an event; Service B listens to that event and starts.

  • Pros: Highly decoupled, independent scaling, easy to add new services without changing existing ones.

  • Cons: Harder to visualize the entire workflow, difficult to track state or manage distributed transactions (requires the Saga Pattern).

Rule of Thumb: Use Orchestration (Step Functions) inside a microservice boundary to manage complex local workflows. Use Choreography (EventBridge) between different microservices to keep them decoupled.

4. AppSync (GraphQL)

AWS AppSync is a managed service that makes it easy to build applications using GraphQL.

  • The GraphQL Advantage: Unlike REST, where you have multiple endpoints (/users, /posts), GraphQL uses a single endpoint. The client explicitly requests exactly the data it needs using a query, preventing over-fetching or under-fetching.

  • Data Declarations (Resolvers): AppSync connects your GraphQL schema directly to data sources (DynamoDB, Lambda, Aurora) using JavaScript or VTL resolvers.

  • Real-time with Subscriptions: AppSync leverages WebSockets under the hood automatically. When data changes via a GraphQL mutation, AppSync pushes updates instantly to subscribed clients.

  • Best for: Mobile and web applications with complex, relational data requirements, data aggregation from multiple backends, or real-time UI updates.

5. Core Messaging Patterns

Understanding these patterns is critical to designing reliable cloud architectures.

  • Fan-out: * What it is: Sending a single message to multiple destinations simultaneously.

    • How to do it on AWS: Combine SNS and SQS. Publish a message to an SNS topic, and subscribe multiple SQS queues to that topic. Each queue gets a copy of the message to process independently.

  • Pub/Sub (Publish/Subscribe): * What it is: An asynchronous messaging model where senders (publishers) don’t send messages directly to specific receivers (subscribers), but instead characterize published messages into classes.

    • How to do it on AWS: Use SNS for high-throughput messaging or EventBridge if you need advanced payload filtering.

  • FIFO (First-In-First-Out): * What it is: Strictly preserving the order in which messages are sent and ensuring exactly-once processing (no duplicates).

    • How to do it on AWS: Use SQS FIFO queues or SNS FIFO topics. Note: FIFO reduces maximum throughput compared to standard queues.

  • DLQ (Dead Letter Queue): * What it is: A garbage-collection queue where messages are isolated if they fail to process successfully after a certain number of attempts (Retry Limit / Max Receive Count).

    • How to do it on AWS: Attach an auxiliary SQS queue as a DLQ to your primary SQS queue or Lambda function. This allows you to debug “poison pill” messages without breaking your consumer application.