Designing a Serverless Architecture

Serverless functions execute on-demand without managing servers — ideal for event-driven, variable-load workloads.

Serverless Characteristics

No server management
Auto-scaling (0 to millions)
Pay per execution (not per hour)
Stateless by design
Event-driven triggers

Common Event Triggers

HTTP:       API Gateway → Lambda
Storage:    S3 upload → Lambda (process image)
Database:   DynamoDB Streams → Lambda (replicate)
Schedule:   CloudWatch Events → Lambda (cron)
Message:    SQS/Kafka → Lambda (batch process)
Stream:     Kinesis → Lambda (real-time analytics)

Cold Starts

Cold start: New Lambda container initialized
  Duration: 100ms-2s depending on runtime
  Affects:  First request after idle period

Mitigation:
  Provisioned concurrency: Pre-warm N instances
  Smaller packages: Reduce init time
  Lighter runtimes: Node.js/Python faster than Java
  Connection pooling: Init DB connections in global scope

Function Structure Best Practices

// Init outside handler — runs once per container lifecycle
const db = new DBPool(process.env.DB_URL);
const client = new RedisClient(process.env.REDIS_URL);

exports.handler = async (event) => {
  // Handler runs per invocation
  const userId = event.pathParameters.id;
  const user = await db.query('SELECT * FROM users WHERE id = ?', userId);
  return { statusCode: 200, body: JSON.stringify(user) };
};

Concurrency Model

Each Lambda invocation = 1 container

100 concurrent requests → 100 Lambda containers
  (auto-scale, no config needed)

Reserved concurrency: Cap max concurrent for a function
Provisioned concurrency: Pre-warmed for latency-sensitive

Account limit: Default 1000 concurrent per region

State Management

Lambda is stateless — no local state between invocations

State options:
  Session state:   DynamoDB or Redis
  File operations: S3 (not local disk)
  Workflows:       Step Functions (orchestrate state)
  Cache:           ElastiCache / DAX

Cost Model

Charged per:
  Invocations: $0.20 per 1M
  Duration: $0.0000166667 per GB-second

Optimize:
  Right-size memory (more RAM = faster + more expensive)
  Reduce duration: Optimize code paths
  Batch: Process multiple SQS messages per invocation

When NOT to Use Serverless

Avoid for:
  Long-running tasks (> 15 min Lambda limit)
  Low-latency requiring warm connections always
  CPU-intensive workloads
  High-frequency, sustained traffic (VMs cheaper)

Conclusion

Serverless excels for event-driven, variable, or unpredictable workloads. Cold starts and statelessness are the main challenges — provisioned concurrency and external state management address both.