How do you handle distributed transactions in serverless?

Traditional ACID distributed transactions are impractical in serverless due to stateless functions and eventual consistency of managed services. Patterns for consistency: (1) Saga Pattern — decompose a distributed transaction into a sequence of local transactions, each publishing an event. If a step fails, compensating transactions undo previous steps. Implemented with Step Functions (orchestration saga) or EventBridge (choreography saga). Example: Order → Reserve Inventory → Charge Payment → Confirm Order; if payment fails, release reservation; (2) Outbox Pattern — write the event to an "outbox" table atomically with the business data in a single DynamoDB transaction (TransactWriteItems). A separate Lambda (DynamoDB Streams consumer) publishes outbox events to SQS/EventBridge, ensuring events are published exactly once even on Lambda failure; (3) DynamoDB Transactions (TransactWriteItems) — atomic writes across multiple items/tables within a single AWS region. Limited to 25 items, not cross-service; (4) Idempotency — all operations must be safely retried; use idempotency keys to detect and ignore duplicate executions. Accept eventual consistency as the default; design business flows to tolerate brief inconsistency.