BACKEND

Home › Glossary › Backend· 372 ·

Serverless Functions

\\sur-ver-luhs fuhngk-shuhns\\n. pl.

Filed underBackendApisInfrastructureSoftware Engineering

In brief · quick answer

Serverless functions are single-purpose, event-driven code snippets that run on cloud infrastructure without managing servers. The cloud provider handles scaling, availability, and billing (per-execution).

§ 1 Definition

Serverless functions (also called Functions as a Service or FaaS) are stateless, ephemeral code units that execute in response to events. Despite the name, servers are still involved. You just never deal with them. The cloud provider (AWS Lambda, Vercel Functions, Cloudflare Workers, Google Cloud Functions) manages the runtime, scaling from zero to thousands of concurrent executions based on demand. Serverless functions are event-triggered: an HTTP request, a file upload, a database change, a message queue message, or a scheduled timer. They are stateless by design, meaning each invocation is independent and should not rely on local state. Persistent state must live in external services (databases, object storage, caches). Serverless functions shine for workloads with variable traffic, infrequent usage, or where reducing operational overhead is a priority. They are less suitable for long-running processes, WebSocket connections, or workloads with predictable high traffic where provisioned capacity is cheaper.

§ 2 How Serverless Functions Work

You write a function (Node.js, Python, Go, etc.) with a handler signature. The cloud provider packages it, manages the runtime, and exposes an HTTP endpoint (or event source binding). When a request arrives, the provider spins up a container (or uses a warm one if available), runs the handler, and scales the container down when idle. Cold starts (the initial spin-up when no warm container exists) add latency, typically 100ms to 1 second depending on the runtime and provider. Warm starts are near-instant. Providers keep containers warm for a period (minutes to hours) after the last request. Serverless functions scale horizontally per invocation, with no capacity planning needed.

§ 3 Serverless vs Traditional Backends

Serverless trades operational overhead for cost predictability at low to medium traffic. There is no server provisioning, no OS patching, no capacity planning, and no scaling configuration. The tradeoffs include cold start latency, a maximum execution timeout (typically 15 minutes for Lambda, 10 minutes for Vercel, 30 seconds for Cloudflare), statelessness requirements, and potential cost unpredictability at high traffic volumes. A traditional server (EC2, dedicated VM) with constant high traffic is cheaper per request than serverless. Serverless is most cost-effective when traffic is spiky, unpredictable, or low-volume. Many applications use both: serverless for API endpoints and event handlers, traditional servers for long-running or predictable workloads.

§ 4 Serverless Use Cases

Serverless functions excel in several scenarios. API backends for front-end applications (the BFF pattern) where each route is a function. Webhook handlers that process events from Stripe, GitHub, or Slack. Image processing triggered by file uploads. Scheduled tasks (cron jobs) like data aggregation or report generation. Chatbots and automation workflows. Authentication handlers (login, signup, password reset). Data transformation pipelines that process records in streams. The common thread is short-lived, event-driven, stateless computation.

§ 5 Note

Common misunderstanding: Serverless does not mean no servers. It means you do not manage servers. The servers still exist. Another misconception: serverless is always cheaper. At high sustained traffic, a provisioned server is more cost-effective. Serverless is cost-effective for spiky or low-volume traffic. Also: serverless functions are not stateless. They are ephemeral, but you should code as if each invocation could get a fresh container. Do not store state in local variables or the filesystem.

§ 6 In code

```javascript
// AWS Lambda handler (Node.js)
export const handler = async (event) => {
  const { userId } = event.pathParameters;
  
  const user = await db.query(
    'SELECT id, name, email FROM users WHERE id = $1',
    [userId]
  );
  
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(user)
  };
};
```

§ 7 Common questions

Q. What is a cold start?: A. A cold start happens when a serverless function hasn't been used recently and the provider needs to spin up a new container. This adds 100ms-1s of latency. Strategies to mitigate include provisioned concurrency (AWS) or keeping functions warm with pings.
Q. Can I use WebSockets with serverless?: A. It is possible but difficult. AWS API Gateway supports WebSocket connections to Lambda, but long-lived connections are not serverless functions' natural habitat. For WebSockets, consider a traditional server or a managed service like Pusher.
Q. Which provider should I choose?: A. AWS Lambda is the most mature and feature-rich. Vercel Functions are great if you are already on Vercel. Cloudflare Workers have the lowest cold starts (near-zero) and run at the edge.

Key takeaways

Serverless functions run on cloud infrastructure without server management.
Event-triggered, stateless, and scale from zero to thousands automatically.
Cold starts add latency; mitigate with provisioned concurrency or choose edge runtimes.
Best for spiky or low-volume traffic; traditional servers are cheaper at sustained high traffic.

How Atomic Glue helps

Atomic Glue builds serverless backends for clients who need automatic scaling and zero server management. We deploy serverless functions on AWS Lambda, Vercel Functions, and Cloudflare Workers depending on your traffic patterns and latency requirements. Serverless is our default choice for API endpoints, webhook handlers, and event-driven processing. If your traffic is spiky or unpredictable, serverless saves you both engineering time and infrastructure cost. This is a core offering within our Web Development services. Get in touch to discuss your serverless architecture.

Get in touch

# Serverless Functions

Category: Backend (also: Apis, Infrastructure, Software Engineering)

Author: Atomic Glue Development Team

## Definition

## How Serverless Functions Work

## Serverless vs Traditional Backends

## Serverless Use Cases

## Note

## In code

## Common questions
Q: What is a cold start?
A: A cold start happens when a serverless function hasn't been used recently and the provider needs to spin up a new container. This adds 100ms-1s of latency. Strategies to mitigate include provisioned concurrency (AWS) or keeping functions warm with pings.
Q: Can I use WebSockets with serverless?
A: It is possible but difficult. AWS API Gateway supports WebSocket connections to Lambda, but long-lived connections are not serverless functions' natural habitat. For WebSockets, consider a traditional server or a managed service like Pusher.
Q: Which provider should I choose?
A: AWS Lambda is the most mature and feature-rich. Vercel Functions are great if you are already on Vercel. Cloudflare Workers have the lowest cold starts (near-zero) and run at the edge.

## Key takeaways

Serverless functions run on cloud infrastructure without server management.
Event-triggered, stateless, and scale from zero to thousands automatically.
Cold starts add latency; mitigate with provisioned concurrency or choose edge runtimes.
Best for spiky or low-volume traffic; traditional servers are cheaper at sustained high traffic.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/serverless-functions