What is CQRS and how does it apply to serverless architectures?

CQRS (Command Query Responsibility Segregation) separates read (Query) operations from write (Command) operations, using different models and potentially different data stores for each. In serverless: Write side (Commands): API Gateway → Lambda command handler → validates business rules → writes to DynamoDB (event store or write model). Lambda for writes is transient — invoked on demand, scales with write load. Read side (Queries): DynamoDB Streams → Lambda projector → updates read-optimized DynamoDB table, Elasticsearch, or S3 for analytics. Read models are pre-computed denormalized views. Different API Gateway endpoints (or even separate API stages) route to different Lambda functions for reads vs. writes. Benefits in serverless: read and write Lambda functions scale independently (a viral event causing massive reads doesn't starve writes); separate IAM roles for read/write Lambdas enforce least privilege; read models are optimized for specific access patterns (avoiding expensive DynamoDB scans). Challenge: eventual consistency — read models lag behind writes by the time it takes projectors to process DynamoDB Streams events (typically <100ms).