Serverless Architecture Patterns

Serverless architecture on AWS shifts compute responsibility from long-running infrastructure to ephemeral, event-driven functions, but it does not eliminate architectural complexity. AWS Lambda introduces a different set of design considerations around invocation models, concurrency control, failure handling, and downstream protection that architects must evaluate as carefully as they would EC2 fleet sizing or container orchestration. Treating Lambda as simply “code without servers” overlooks the operational and architectural decisions required to build reliable serverless systems.

Event-driven execution model

AWS Lambda decouples compute from infrastructure provisioning by executing function code only in response to events. The event source determines not just when a function runs, but also how it runs, how failures propagate, and how tightly the caller is coupled to the function’s success or failure. Three invocation models govern this behavior.

• Synchronous invocation occurs when the caller, such as API Gateway or an Application Load Balancer, sends a request and blocks until Lambda returns a response. The caller owns retry logic, and any function error surfaces directly to the end user.

• Asynchronous invocation occurs when services like S3, SNS, or EventBridge deliver an event to Lambda’s internal queue and return immediately. Lambda manages retries (up to two additional attempts) and can route failures to a Lambda destinationA configured target (SQS, SNS, EventBridge, or another Lambda) that receives the invocation result record after successful or failed async execution, enabling decoupled failure handling without custom code.

• Poll-based invocation occurs when Lambda’s event source mappingAn internal poller that Lambda manages to read records from streaming or queue sources like SQS, Kinesis, and DynamoDB Streams, controlling batch size, concurrency, and failure behavior per shard or queue actively retrieves records from the source.

Each invocation model carries a different retry behavior. Synchronous invocations return errors directly to the caller with no automatic retry. Asynchronous invocations retry twice with a backoff before routing failures to a dead-letter queue or destination. Poll-based invocations retry entire batches until records expire or partial batch failure reporting is enabled. Choosing the wrong invocation model can introduce tight coupling, uncontrolled retries, or silent data loss.

The following diagram illustrates how each invocation model handles event flow, retry paths, and failure ...