Serverless and FaaS: Event-Driven Compute Without Managing Servers

Why Serverless?

Serverless is an execution model where the cloud provider manages the servers, runtime scaling, patching, capacity planning, and much of the operational plumbing. You still write code and own the architecture, but you do not provision long-running application servers for every workload.

Function-as-a-Service (FaaS) is the most common serverless compute model. You deploy small functions, and the platform runs them in response to events.

Traditional Compute vs Serverless

Function-as-a-Service

In FaaS, each function has a trigger, handler, runtime, configuration, and permissions.

Common Triggers

Handler Shape

type OrderPlacedEvent = {
  orderId: string;
  customerId: string;
  totalAmount: number;
};

export async function handleOrderPlaced(event: OrderPlacedEvent) {
  await reserveInventory(event.orderId);
  await sendConfirmationEmail(event.customerId);

  return { status: "accepted" };
}

The handler should be small, idempotent, and explicit about dependencies. Heavy orchestration, long waits, and hidden shared state make functions difficult to reason about.

Statelessness

Serverless functions can be reused between invocations, but you must not depend on local process memory for correctness. The platform may start a new execution environment at any time.

What Can Live Inside the Function?

Cold Starts

A cold start happens when the platform must create a new execution environment before running your handler. The delay includes container setup, runtime startup, dependency loading, and initialization code.

Reducing Cold Start Impact

Cold starts matter most on synchronous user-facing paths. They matter less for background processing, scheduled jobs, and event consumers where a few hundred milliseconds do not affect user experience.

Event-Driven Serverless Workflows

Serverless works best when the system is naturally event-driven. A function receives an event, performs one bounded action, emits another event, and exits.

Orchestration vs Choreography

Use orchestration when the process needs explicit retries, compensation, human-visible status, or strict ordering. Use choreography when downstream reactions can evolve independently.

Limits and Constraints

Serverless platforms intentionally limit execution. Those limits are part of the architecture.

Data Access Patterns

Direct Function to Database

Simple, but high concurrency can create too many database connections.

Queue Buffered Writes

Better for smoothing spikes and protecting downstream systems.

Managed Service First

Good for file processing, analytics pipelines, and asynchronous workflows.

Observability

Serverless systems are distributed systems. You need correlation IDs, structured logs, metrics, and traces from the start.

When to Use Serverless

Common Anti-Patterns

What to Remember for Interviews

1. Serverless shifts operations: You manage architecture and code; the provider manages runtime capacity.
2. Functions are stateless: Store durable state externally.
3. Cold starts are workload-dependent: Critical for synchronous APIs, less critical for async jobs.
4. Design for retries: At-least-once delivery means idempotency is mandatory.
5. Protect downstream systems: Function scaling can overwhelm databases and third-party APIs.