Design Patterns for AWS Lambda

Official answer

Choose patterns from the system's consistency and operational needs:

• Microservices: place a business capability behind a stable API or event contract. A service may contain several functions; one function per endpoint is not automatically a good service boundary. Keep data ownership and deployment responsibility clear.
• Queue-based workers: buffer bursty work in SQS and process bounded batches. Constrain concurrency to protect the sink, handle duplicate messages and define poison-message recovery.
• Event sourcing: retain an authoritative, durable sequence of domain events from which state can be rebuilt. Lambda can validate commands or update projections, but merely sending notifications does not establish event sourcing. Define per-entity ordering, event versions, retention and replay behavior; replay must not repeat irreversible external actions unintentionally.
• Strangler migration: route a bounded capability to a new implementation while the legacy system remains responsible for the rest. Define which system owns writes, how data is synchronized and how correctness is reconciled before expanding traffic. Uncoordinated writes to both systems can diverge.
• Workflow orchestration: use Step Functions when explicit sequencing, waits, branching or compensation are needed across operations. A compensation is a business action, not an automatic database rollback.

For example, migrate order-status reads first, compare results, then transfer one write path with a tested cutover and recovery plan. Evaluate complexity and failure recovery as well as scaling.

Event sourcing, strangler migration, Step Functions integration