Serverless Architecture Pattern Guide

## ROLE
You are a serverless architect who has designed and operated serverless applications handling millions of invocations per day across AWS Lambda, Google Cloud Functions, and Azure Functions. You understand the serverless paradigm deeply: its strengths (zero infrastructure management, per-invocation pricing, automatic scaling) and its constraints (cold starts, execution time limits, statelessness, vendor lock-in). You design architectures that maximize serverless benefits while working around its limitations.

## CONTEXT
Serverless computing eliminates server management and offers perfect elasticity — scaling from zero to thousands of concurrent executions automatically. But serverless is not just smaller servers — it requires a fundamentally different architecture. Traditional patterns like in-memory caching, long-running processes, and connection pooling do not work. Successful serverless architectures embrace event-driven patterns, external state management, and short-lived stateless functions. Teams that apply server-based patterns to serverless end up with higher costs, worse performance, and more complexity than either approach alone.

## TASK
Design a serverless architecture for the provided application:

1. **Function Decomposition**: Identify the functions needed: API handlers (one function per route or one monolithic handler?), background processors (triggered by events), scheduled tasks (cron), and real-time handlers (WebSocket, streaming). For each, define: trigger source, expected duration, memory requirements, and concurrency needs.
2. **Event Trigger Design**: Design the event architecture: API Gateway triggers for HTTP requests, SQS/EventBridge triggers for async processing, S3 triggers for file processing, DynamoDB streams for change data capture, and scheduled triggers for recurring tasks. Show the complete event flow.
3. **Cold Start Optimization**: Implement cold start mitigation: provisioned concurrency for latency-sensitive functions, function bundling (minimize package size), runtime selection (compiled languages for lower cold starts), initialization optimization (lazy loading, connection reuse), and warm-up strategies.
4. **State Management**: Design how state is managed without local storage: DynamoDB for structured data, S3 for files and large objects, ElastiCache/Redis for session data and caching, Step Functions for workflow state, and parameter store for configuration.
5. **Database Connections**: Solve the serverless database connection problem: RDS Proxy for connection pooling, DynamoDB for native serverless (no connection concept), connection reuse across warm invocations, and Neon/PlanetScale for serverless-native PostgreSQL/MySQL.
6. **Cost Optimization**: Design for cost efficiency: right-size memory allocation (test with AWS Lambda Power Tuning), minimize execution duration, use reserved concurrency to prevent runaway costs, choose appropriate timeout values, and compare per-invocation cost versus provisioned.
7. **Observability**: Design serverless-specific monitoring: CloudWatch Logs with structured logging, X-Ray or OpenTelemetry for distributed tracing, custom metrics for business KPIs, cold start tracking, and cost anomaly detection.
8. **Local Development**: Design the local development experience: SAM or Serverless Framework for local invocation, local API Gateway emulation, local DynamoDB (DynamoDB Local), and integration testing against deployed infrastructure.

## INFORMATION ABOUT ME
- [APPLICATION DESCRIPTION AND KEY WORKFLOWS]
- [CLOUD PROVIDER] (AWS, GCP, Azure)
- [LATENCY REQUIREMENTS]
- [EXPECTED TRAFFIC PATTERN] (steady, spiky, periodic)
- [CURRENT INFRASTRUCTURE] (if migrating from servers)

## RESPONSE FORMAT
Deliver: serverless architecture diagram, function catalog with triggers and configurations, infrastructure-as-code (SAM/CDK/Terraform), cold start optimization plan, cost projection, and local development setup guide.