An event-driven AWS application separates synchronous request admission from asynchronous execution, buffering and fan-out. API Gateway can front a request, Lambda performs bounded computation, SQS absorbs a backlog, SNS distributes an event to subscribers, and EventBridge routes events by pattern. When reviewing an SAA-C03 architecture scenario, ask which component absorbs a burst, how failures are retried and where duplicate delivery is handled; that design evidence matters more than naming every AWS service. The separate DOP-C02 credential is not needed to explain the same serverless flow.
The architecture becomes clearer when the question is phrased in terms of delivery semantics. Does the caller need an immediate response? Must work wait safely until a consumer is ready? Should one event be copied to several independent subscribers? Does the producer know the consumers, or should routing rules decide where an event goes? Those questions map directly to the services.
Separate synchronous entry points from asynchronous work
API Gateway is commonly the front door when a client needs an HTTP or REST-style interface. A request can invoke Lambda and return a response immediately. That path is appropriate for work that can complete within the user-facing latency budget and where the caller needs to know whether the operation succeeded. Authentication, throttling, request validation, and API lifecycle controls can be applied at the edge of the application rather than reimplemented inside every function. The main architectural benefit is decoupling: producers can hand off work or events without requiring every downstream consumer to be available in the same request path.
Problems begin when a synchronous request is forced to wait for work that does not need to finish before the client gets a response. Image processing, email delivery, analytics enrichment, report generation, and downstream integration can all extend latency and increase failure coupling. Instead, the synchronous function can validate the request, persist the necessary state, and place an asynchronous message or event onto the appropriate service. The user gets a fast acknowledgment while the backend continues independently.
This is one reason the broader concept of serverless application design is more useful than thinking of Lambda as a server replacement. The architecture is defined by managed event sources, execution boundaries, state, and failure handling.
Use SQS when work must wait safely for a consumer
Amazon SQS is a queue. Producers send messages, and consumers retrieve them when they have capacity. Lambda can integrate with SQS through an event source mapping: Lambda polls the queue on the application’s behalf and invokes the function with batches of messages. That pull-based behavior creates a durable buffer between the producer’s arrival rate and the consumer’s processing rate.
This makes SQS a strong fit for smoothing bursts, protecting a downstream database, retrying work after transient failures, and scaling consumers independently of producers. If an order service receives 20,000 requests in a short promotion window but the fulfillment backend can process only a few hundred operations per second, the queue absorbs the mismatch rather than forcing the front end to fail whenever the backend is busy.
Visibility timeout, retry behavior, batch size, message retention, and dead-letter queue configuration are part of the design. A consumer must be idempotent because standard queues can deliver a message more than once. FIFO queues add ordering and deduplication features when the workload actually needs those semantics, but they should be chosen because ordering is a business requirement, not as a default.
Use SNS for push-based fan-out to known subscribers
Amazon SNS follows a publish-subscribe model. A publisher sends a message to a topic, and the topic pushes a copy to subscribers such as SQS queues, Lambda functions, HTTP/S endpoints, and other supported destinations. This is a natural way to fan out the same business event to several independent consumers without the producer making separate calls to each system.
For example, an order-completed event might need to trigger fulfillment, customer notification, fraud analytics, and a data-warehouse ingestion path. One SNS topic can distribute the event, while each subscriber owns its own processing. A particularly resilient pattern is SNS-to-SQS fan-out: SNS copies the event to several queues, and each downstream team gets its own durable backlog, retries, and scaling behavior.
The difference between SNS and SQS is operational: SNS distributes an event to subscribers, while SQS holds each consumer’s work until that consumer is ready. They are complementary rather than interchangeable. SNS answers “who should receive a copy now?” while SQS answers “what work should wait until this consumer can process it?”
Use EventBridge when routing should be based on event meaning
Amazon EventBridge is an event bus. Producers put events onto a bus, and rules match fields in those events and route them to targets. The producer does not need to know the subscribers. That is an important architectural difference from a tightly coupled integration in which application code contains the address of every downstream system.
EventBridge becomes especially useful when an organization wants event schemas and business meaning to drive routing. A rule can match an event source, detail type, account, Region, or fields inside the event detail. Different teams can add rules without requiring the producer to change. EventBridge also integrates with AWS services and SaaS sources, making it useful for platform events as well as application events.
The service should not be treated as a general-purpose queue. Its normal event-routing model is near-real-time matching and delivery, while SQS is designed to hold messages until consumers retrieve them. EventBridge has retry, dead-letter, archive, and replay capabilities, but if the core requirement is a durable backlog consumed at the receiver’s pace, SQS remains the simpler primitive. If the core requirement is rule-based event distribution across loosely coupled systems, EventBridge is usually the better fit.
Lambda can be triggered by push or by managed polling
AWS Lambda documentation distinguishes direct invocation from event source mappings. Some services push events to Lambda. API Gateway, EventBridge, and SNS can invoke functions as events arrive. Other services such as SQS are read by Lambda through an event source mapping, where Lambda manages polling and invokes the function when records are available.
This distinction affects failure handling. With an SQS event source mapping, a failed batch normally becomes visible for another attempt after the visibility timeout, including messages that may already have succeeded. Configuring ReportBatchItemFailures and returning the failed message IDs lets the mapping retry only those records when the function correctly implements partial batch responses. With asynchronous Lambda invocation from a push source, Lambda has its own retry and destination behavior. With a synchronous API request, the caller receives the error and may choose whether to retry. Architecture diagrams that draw every arrow as equivalent hide these important operational differences.
Concurrency is also part of the contract. A fast event source can create large Lambda concurrency, which might be exactly what the application needs or might overwhelm a relational database, third-party API, or rate-limited backend. SQS can help absorb load, and reserved concurrency or other controls can bound function execution. Event-driven does not mean unbounded.
Design for duplicates, retries, poison messages, and partial failure
Distributed systems eventually encounter failures that a happy-path diagram does not show. Network timeouts can make a producer unsure whether a request completed. At-least-once delivery can produce duplicates. A malformed message can fail repeatedly. One downstream subscriber can be unavailable while all other subscribers continue normally. An event-driven architecture is resilient only if these cases are deliberate.
Idempotency is one of the most important application techniques. If the same event is processed twice, the result should be safe. An order-payment handler can claim a stable business idempotency key with a durable conditional write and, where supported, pass the same key to the payment provider. If the external charge outcome is uncertain, the handler must reconcile that result before retrying instead of assuming that a stored key prevented duplicate payment. A data-processing function might use a conditional write or unique identifier so a duplicate event does not create a second logical record. Retrying an operation should be part of the design, not an emergency assumption.
Dead-letter queues or equivalent failure destinations provide a place to isolate messages that cannot be processed normally. Operators can inspect the payload, determine whether the problem is data or code, correct the cause, and then replay or redrive safely. Metrics should track queue age, backlog depth, function errors, throttling, rule failures, and dead-letter activity so delayed work does not remain invisible.
A good service combination follows the business flow
Imagine an ecommerce checkout. API Gateway accepts the request and invokes a Lambda function that validates the customer and writes an order record. The function then publishes an order-created event. EventBridge routes that event to different business domains based on event content. Fulfillment receives work through SQS so it can process at a controlled rate. A notification topic in SNS fans status updates to several channels. None of those services is redundant because each solves a different delivery problem.
A media-processing application might look different. The upload itself could land in object storage and generate an event. SQS can buffer processing jobs for Lambda or container workers. EventBridge can route lifecycle events to audit, billing, or workflow systems. API Gateway might exist only for control operations. The architecture should use the fewest event primitives that express the required behavior clearly rather than forcing every AWS messaging service into one diagram.
Security boundaries remain important. IAM roles should give producers only the ability to publish to their intended destinations and give consumers access only to the data they need. KMS encryption, resource policies, VPC endpoints, logging, and cross-account event permissions can all matter depending on the architecture. Serverless removes server administration; it does not remove authorization design.
Read architecture scenarios by delivery semantics
In certification and real design reviews, certain requirements are strong signals. A durable backlog and consumer-controlled processing pace point toward SQS. One-to-many push fan-out points toward SNS. Rich rule-based routing from many event sources points toward EventBridge. An HTTP entry point with an immediate response points toward API Gateway and a synchronous integration. Lambda is the compute layer that can sit behind any of these, but it does not replace the messaging semantics.
The most robust architecture often combines services. API Gateway can handle the synchronous boundary, Lambda can validate and transform, EventBridge can route business events, SNS can broadcast notifications, and SQS can protect downstream workers from bursts and outages. The design stays understandable when each component has one clear responsibility.
That is the durable lesson behind event-driven architecture on AWS: separate the caller’s timeline from background work, separate producers from consumers, and make delivery behavior explicit. Once those boundaries are clear, service selection becomes an engineering decision rather than a memorization exercise.