Serverless Architecture — When It's Perfect and When It's a Trap

Serverless doesn't mean no servers#

It means you don't manage them. Someone else does. You write functions, deploy them, and pay per invocation. No provisioning, no patching, no capacity planning.

That's the promise. Here's the reality.

What serverless actually is#

Functions as a Service (FaaS)#

AWS Lambda, Google Cloud Functions, Cloudflare Workers. Write a function, trigger it with an HTTP request or event.

export async function handler(event) {
  const { userId } = JSON.parse(event.body);
  const user = await db.get(userId);
  return { statusCode: 200, body: JSON.stringify(user) };
}

You provide: Code. They provide: Everything else (runtime, scaling, monitoring).

Backend as a Service (BaaS)#

Firebase, Supabase, AWS Amplify. Pre-built backend services you compose together.

• Auth: Firebase Auth, Cognito
• Database: Firestore, DynamoDB
• Storage: S3, Cloud Storage
• Messaging: SNS, Pub/Sub

You don't write backend code — you configure services and call them from your frontend.

When serverless is perfect#

Event-driven processing. Image uploaded → resize it. Payment received → send receipt. User signed up → send welcome email. Serverless excels at reacting to events.

Variable traffic. Your API gets 10 requests per hour most of the time, then 10,000 during a sale. Serverless scales to zero (no cost) and scales to thousands (no capacity planning).

MVPs and prototypes. Ship fast without DevOps. Focus on product, not infrastructure. Firebase + Lambda + Vercel can get you to market in days.

Cron jobs and webhooks. Scheduled tasks that run for 30 seconds then stop. No need to keep a server running 24/7 for a job that runs once per hour.

When serverless is a trap#

Long-running processes. Lambda has a 15-minute timeout. If your job takes longer, you need a different solution.

Cold starts. First invocation after idle can take 1-5 seconds (especially with Java/.NET). For user-facing APIs where latency matters, this is painful.

Complex stateful applications. Serverless functions are stateless. If your app needs persistent connections (WebSockets), background workers, or in-memory caches, serverless fights you.

Cost at scale. Serverless is cheap at low volume. At high volume (millions of invocations/day), a dedicated server is 5-10x cheaper. Do the math.

Vendor lock-in. Your Lambda functions use AWS-specific APIs, DynamoDB Streams, and SQS triggers. Moving to GCP means rewriting everything.

The cost crossover#

At low volume, serverless wins on simplicity. At high volume, dedicated wins on cost. The crossover is usually around 10-50M invocations/month.

The hybrid approach#

Most production systems use a mix:

• Serverless for webhooks, cron jobs, image processing, and APIs with variable traffic
• Containers for core services with predictable load and long-running processes
• Edge functions (Cloudflare Workers, Vercel Edge) for low-latency middleware

Don't go all-in on either approach. Use each where it fits.

See serverless in your architecture#

On Codelit, generate any system and you'll see which components are best suited for serverless vs containers. The architecture visualizes the data flow so you can identify event-driven patterns that are natural fits for Lambda/Functions.

---

Design your serverless architecture: describe your system on Codelit.io and identify which components should be serverless.