Serverless Compute

Serverless is a cloud model where you run code without managing servers. Despite the name, servers still exist — you just don't provision, scale, or maintain them. You write a function, deploy it, and pay only for the time it actually runs. If Cartara flagged this in your diff, you likely added a serverless function, changed how one handles state, or hit a pattern that breaks in a serverless environment (like holding a database connection open).

How it works

When a request comes in, the cloud provider spins up a container to run your code, executes the function, and tears the container down (or keeps it warm briefly for future calls). You don't decide how many copies run — the platform handles that automatically.

Cold start vs warm start is the key trade-off:

• Cold start: A fresh container has to spin up. This adds latency — typically 100ms to 2 seconds depending on the runtime and provider
• Warm start: A recently-used container is reused. Near-instant execution

Cold starts matter most for latency-sensitive user-facing code. They matter less for background tasks.

What triggers a serverless function

Functions don't run on their own. They respond to events:

The statelessness constraint

Serverless functions are stateless by design. Each invocation is independent — you can't rely on in-memory data persisting between calls. One run might happen on a completely different container than the last one.

This means any state that needs to persist across requests must live outside the function: in a database, object storage, or a cache. This is the most common thing builders get wrong.

// Broken: assumes data persists in memory between calls
let callCount = 0  // this resets on every cold start

export async function handler(event) {
  callCount++  // unreliable across instances
  return { count: callCount }
}

// Correct: state stored in a database
export async function handler(event) {
  const result = await db.counters.upsert({
    where: { id: 'global' },
    update: { count: { increment: 1 } },
    create: { id: 'global', count: 1 }
  })
  return { count: result.count }
}

When serverless is a good fit

• Unpredictable or spiky traffic — scales to zero and to thousands instantly
• Event-driven workloads — responding to uploads, messages, webhooks
• Background tasks — image processing, email sending, data transformation
• APIs with variable load — you pay only for actual usage
• Side projects — generous free tiers make it nearly free at low volume

When serverless is a poor fit

• Long-running processes — most providers cap execution time (AWS Lambda: 15 minutes max)
• Latency-critical paths where cold starts are unacceptable
• Stateful workloads that need persistent in-memory state
• High sustained throughput — at scale, always-on containers often cost less
• ML model serving with large models that take too long to load

The database connection problem

This trips up many serverless builders. A traditional server opens a database connection once and reuses it. A serverless function might spin up 1,000 instances simultaneously — each wanting its own connection. Most databases have a connection limit, and you'll exhaust it.

The fix is a connection pooler (PgBouncer, or the built-in pooler on Supabase/Neon). It maintains a shared pool of connections that functions borrow and return. Enable this before deploying serverless functions that touch a database.

// Use the pooled connection string, not the direct one
// Supabase example:
const db = new PrismaClient({
  datasources: {
    db: {
      url: process.env.DATABASE_URL  // should point to PgBouncer/pooler, not direct DB
    }
  }
})

What You'll See in Your Code

Cartara commonly flags synchronous fan-out patterns that create cascading latency in serverless:

// Slow: calling multiple lambdas synchronously
export async function processOrder(event) {
  await sendConfirmationEmail(event.orderId)    // wait 300ms
  await updateInventory(event.orderId)           // wait 200ms
  await notifyWarehouse(event.orderId)           // wait 400ms
  // Total: ~900ms, and each failure blocks the others
}

// Better: trigger async jobs via a queue
export async function processOrder(event) {
  await queue.sendBatch([
    { type: 'send_confirmation', orderId: event.orderId },
    { type: 'update_inventory', orderId: event.orderId },
    { type: 'notify_warehouse', orderId: event.orderId },
  ])
  return { status: 'queued' }  // returns fast, work happens in background
}

Providers at a glance

Serverless vs containers

Serverless wins at low traffic, simplicity, and zero idle cost. Containers win at sustained high throughput, long-running processes, and predictable cost. The line is blurring — services like Cloud Run and AWS Fargate are "serverless containers" where you define a container but the platform manages scaling.

Related Concepts

• Cloud Provider Overview
• Database Scaling and Performance
• From Prototype to Production
• Message Queues and Async Processing
• Observability Deep Dive