APIs, Queues, Topics, Events, and Workflows

Goal

Now that the contract is clear, AWS service names can become useful vocabulary.

This section compares common AWS integration choices by communication intent: API Gateway, SQS, SNS, EventBridge, Step Functions, Lambda, and container workers.

The Short Version

AWS integration services are easiest to compare by the kind of communication they support.

Client -> API Gateway -> order service
                         |
                         +-> SQS queue -> worker
                         +-> SNS topic -> subscribers
                         +-> EventBridge bus -> routed targets
                         +-> Step Functions workflow -> coordinated steps

Lambda and containers usually do the work behind these patterns. They are processors, not the communication contract by themselves.

Service Families By Intent

Intent	AWS Service Family	Use When
Expose an API	API Gateway	Clients need a managed HTTP, REST, or WebSocket entry point with auth, throttling, monitoring, and backend integration.
Buffer work	SQS	Producers and consumers should not have to move at the same speed.
Fan out notifications	SNS	One publisher needs to push a message to multiple subscribers.
Route events	EventBridge	Events need rule-based routing across AWS services, applications, SaaS integrations, or accounts.
Orchestrate process	Step Functions	A process needs state, branching, retries, timeouts, human-visible execution, or multi-step coordination.
Process work	Lambda or containers	Code needs to handle API requests, queue messages, events, or workflow tasks.

This table is intentionally practical. In real designs, these services often combine.

SQS, SNS, EventBridge, and Step Functions

The most common confusion is between SQS, SNS, EventBridge, and Step Functions.

SQS is a queue. It holds work until a consumer can process it. It is strong when you want buffering, decoupling, retry behavior, and a consumer-controlled pace.

SNS is a topic-based pub/sub service. A publisher sends a message to a topic, and subscribers receive it. It is strong for fanout, such as sending the same order-created notification to multiple queues, Lambda functions, HTTP endpoints, or notification targets.

EventBridge is an event bus and routing layer. It is strong when the event source and target should be connected through rules, filters, integrations, and event-driven routing rather than direct subscriptions only.

Step Functions is workflow orchestration. It is strong when the process itself has state: call payment, wait, branch on result, reserve inventory, retry fulfillment, compensate on failure, and record the final outcome.

Where Lambda And Containers Fit

Lambda or containers run the processing code. For example:

API Gateway can invoke Lambda or route to a containerized service.
SQS can trigger Lambda or be polled by a container worker.
EventBridge can invoke Lambda, start workflows, or send events to other targets.
Step Functions can call Lambda functions, AWS service integrations, or container tasks.

Choose the processor using the compute model from Chapter 11: runtime needs, duration, packaging, scaling behavior, team skill, and operational ownership. Choose the integration pattern using this chapter's contract model.

Example: Order Intake

An order service might use:

API Gateway for checkout requests from clients.
A service on Lambda or ECS/Fargate to validate the request and create the order.
SQS for fulfillment work that should survive consumer delays.
SNS or EventBridge to notify analytics, email, inventory, and partner systems.
Step Functions for payment verification and exception handling when the process has multiple states.

This is not service collecting. Each service has a communication job.

Common Mistakes

Choosing EventBridge when a simple queue is enough.
Using SNS fanout when each consumer really needs independent buffering, retry, and dead-letter handling.
Treating Step Functions as just a visual wrapper instead of stateful orchestration.
Forgetting that Lambda or containers still need observability, permissions, retries, and idempotency.
Letting service preference replace communication intent.

If Someone Asks You

How would you compare SQS, SNS, EventBridge, and Step Functions?

A good answer is:

SQS is a queue for durable buffered work. SNS is pub/sub fanout from a topic to subscribers. EventBridge is an event bus for routing events by rules across services, applications, and integrations. Step Functions is workflow orchestration for stateful multi-step processes. I compare them by intent: buffer, notify, route, or orchestrate.

What You Should Remember

Compare integration services by intent: call, buffer, notify, route, or orchestrate.

Questions to Check Your Understanding

What makes SQS different from SNS?
What kind of problem does Step Functions solve?
Why might a processor be Lambda in one design and a container worker in another?