Serverless Applications: Complete Guide

# A workload is "serverless" when it has these traits:

# 1. No server management by you
#    No VM/OS provisioning, patching, cluster capacity planning,
#    or always-on instances to maintain.

# 2. On-demand execution
#    Code runs when triggered by an event:
#    HTTP request, file upload, queue message, scheduled job, etc.

# 3. Automatic scaling
#    The platform scales concurrency/instances automatically
#    based on load (often including scale-to-zero).

# 4. Usage-based pricing
#    You pay for actual execution/requests
#    rather than idle capacity.

# Important: "Serverless" is an architecture style,
# not a single service.

# Pattern A: Request/Response API
# ─────────────────────────────────
# Trigger:  HTTP request (GET /users, POST /orders)
# Compute:  Function/container handles request
# Services: Database + Auth + Caching (optional)

# Example: REST API handler (pseudo-code)
async function handleRequest(event) {
  const userId = event.pathParameters.id;

  // Auth check (managed auth service)
  const user = await authService.verify(event.headers.token);

  // Business logic
  const data = await database.query(
    'SELECT * FROM orders WHERE user_id = ?', [userId]
  );

  // Return response
  return {
    statusCode: 200,
    body: JSON.stringify(data)
  };
}

# Use when:
# - Building REST/GraphQL APIs
# - Mobile/web backends
# - Microservices

# Pattern B: Event-Driven Pipeline
# ─────────────────────────────────
# Trigger:  File upload / event bus event
# Compute:  Function processes event
# Services: Storage + DB + Notifications

# Example: Image processing pipeline (pseudo-code)
async function processImage(event) {
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;

  // Download original
  const image = await storage.get(bucket, key);

  // Generate thumbnail
  const thumbnail = await sharp(image)
    .resize(200, 200)
    .toBuffer();

  // Save thumbnail
  await storage.put(bucket, 'thumbnails/' + key, thumbnail);

  // Update database
  await database.update('images', {
    key, thumbnailReady: true
  });

  // Notify
  await eventBus.publish('image.processed', { key });
}

# Use when:
# - Media processing (thumbnails, transcoding)
# - ETL-like flows
# - Webhook handlers

# Pattern C: Async Queue Worker
# ─────────────────────────────────
# Trigger:  Queue message (SQS, RabbitMQ, etc.)
# Compute:  Worker function/container
# Services: Queue + Retries + Dead-letter handling

# Example: Email sender with retry (pseudo-code)
async function sendEmailWorker(event) {
  for (const record of event.Records) {
    const message = JSON.parse(record.body);

    try {
      await emailService.send({
        to: message.recipient,
        subject: message.subject,
        body: message.template
      });
      console.log('Email sent to', message.recipient);
    } catch (error) {
      // Message returns to queue for retry
      // After max retries -> dead-letter queue
      throw error;
    }
  }
}

# Use when:
# - Sending emails/notifications
# - Long-ish or retry-prone tasks
# - Smoothing traffic spikes

# Serverless Tradeoffs / Gotchas

# COLD STARTS (latency spikes)
# If a function scales from zero, first request is slower.
# Severity depends on: runtime, config, package size, VPC.
# Mitigations: provisioned concurrency, smaller packages,
#              choose faster runtimes (Go/Rust vs Java).

# DISTRIBUTED COMPLEXITY
# More managed components and event flows means:
# - Stronger need for tracing/log correlation
# - Careful error handling and retries
# - Clear boundaries and contracts between services

# LIMITS AND CONSTRAINTS
# - Max execution time (e.g., 15 min for Lambda)
# - Payload size limits (e.g., 6 MB sync, 256 KB async)
# - Concurrency limits (default 1000, can be raised)
# - VPC access can add cold start latency

# VENDOR LOCK-IN
# Serverless often uses provider-specific services.
# Good abstraction helps, but full portability is hard.

# COST SURPRISES
# Pay-per-use is great for spiky workloads.
# But constant high-volume traffic can get expensive
# vs reserved capacity. Monitor usage early!

# Serverless Design Principles (Practical)

# 1. Make handlers STATELESS and IDEMPOTENT
#    - Stateless: don't rely on local memory between requests
#    - Idempotent: safe to retry without duplicate side effects
#    - Common with queues and at-least-once delivery

# 2. Treat events as the CONTRACT
#    - Version event schemas
#    - Validate inputs defensively
#    - Include correlation IDs for tracing

# 3. Prefer ASYNC for slow work
#    - Keep request/response paths fast
#    - Move heavy steps to queues/events
#    - Example: return 202 Accepted, process in background

# 4. Use LEAST-PRIVILEGE permissions
#    - Each function gets only what it needs
#    - Function A: read from DB table X
#    - Function B: write to bucket Y

# 5. Build strong OBSERVABILITY from day 1
#    - Structured logs (JSON, not plaintext)
#    - Metrics for errors/latency/retries
#    - Distributed traces across services

# Challenge 1: Serverless Fundamentals
#
# Answer these questions by writing your responses:
#
# Q1: Name the 4 traits that define a serverless workload.
#
# Q2: What is the difference between FaaS and
#     serverless containers?
#
# Q3: Where should you keep state in a serverless app?
#     (Hint: NOT in the compute runtime)
#
# Q4: Name 3 types of triggers/events that can start
#     serverless compute.
#
# Write your answers below:

# Challenge 2: Match the Pattern
#
# For each scenario, identify which serverless pattern
# (A, B, C, or D) is the best fit:
#
# Pattern A: Request/Response API
# Pattern B: Event-Driven Pipeline
# Pattern C: Async Queue Worker
# Pattern D: Scheduled Task
#
# Scenarios:
# 1. User uploads a profile photo that needs to be
#    resized into 3 different sizes.
#
# 2. A mobile app needs a /login endpoint that returns
#    a JWT token.
#
# 3. Every night at 2 AM, aggregate daily sales data
#    into a summary report.
#
# 4. After a user places an order, send a confirmation
#    email (which can fail and needs retries).
#
# 5. A webhook from Stripe notifies you of a successful
#    payment and you need to update the order status.
#
# Write your answers (letter + short explanation):

# Challenge 3: Design a Serverless System
#
# Design a serverless image sharing platform.
# Users can:
# - Upload images (max 10 MB)
# - View a feed of recent images
# - Get notifications when someone likes their image
#
# For each requirement, specify:
# 1. Which serverless pattern you'd use
# 2. What triggers the compute
# 3. What managed services you need
# 4. How you handle failures/retries
# 5. What design principles apply
#
# Also address:
# - How would you handle cold starts for the API?
# - Where would you store image metadata?
# - How would you handle a spike of 10,000 uploads?
#
# Write your architecture design below: