Serverless Architecture: Patterns

"Serverless is not 'No Servers.' It is 'No servers that YOU have to manage'."

The dream of every CEO is to pay $$0$ when no one is using the app and only pay when the credit cards are swiping. Traditional servers (EC2) are "Always On," costing you money even at 3:00 AM when the world is asleep.

Serverless (FaaS) solves this. It allows you to run "Little pieces of code" that only exist for 1 second. But if you build it wrong, you will face the "Cold Start" nightmare and a massive "Spaghetti Cloud." This 1,500+ word guide explores the "State-less" future of computing.

1. Pattern 1: The "Event-Driven" Glue

Serverless is best used as a "Reaction."

Event: A user uploads an image to S3.
Reaction: A Lambda function wakes up, shrinks the image, and saves it.
The Benefit: You don't need a "Server" sitting there waiting for images. You only pay for the $2$ seconds it took to shrink the photo.

2. The "Cold Start": The Architect's Enemy

When your function hasn't run in a while, AWS "Deletes" it to save space. When a user finally clicks, AWS has to "Find and Start" the code.

The Delay: $500$ms to $2$ seconds. (Too long for a website!).
The Solution: Use Zig or Go (for 50ms cold starts) or use "Provisioned Concurrency" to pay a small fee to keep $1$ copy always warm.

3. Pattern 2: The "Backend-for-Frontend" (BFF)

Instead of one giant API, you have $50$ tiny functions.

Function A handles Login.
Function B handles UserSearch.
The Benefit: If the search function has a bug and crashes, the Login site still works. This is "Maximum Fault Tolerance."

4. The "Logic-less" Registry: Step Functions

How do you coordinate $5$ different functions (Billing -> Shipping -> Email)?

The Wrong Way: Function 1 calls Function 2. (This creates a "Dependency Hell").
The Right Way: Use AWS Step Functions or Google Workflows.
It is a "Visual Map" that says: "Run Lambda A. If it succeeds, run B. If it fails, run C." It moves the orchestration OUT of the code and INTO the platform.

5. Security: The "Identity" principal

In serverless, your function is a "Person."

You give it a small IAM Role.
"This function can READ 'Users' table but it cannot DELETE anything."
Even if a hacker hacks the function, they are "Trapped" in the cage you built. This is the Principle of Least Privilege (Module 125).

Summary: The Serverless Checklist

Keep it Stateless: Never store data in the function's "Local RAM." It will vanish in 1 minute.
Optimized cold starts: Use small runtimes (Zig/Rust) or stay warm.
Use Orchestration: Keep your "If/Then" logic in Step Functions, not inside your Lambdas.
Security Gate: Use an API Gateway to protect your functions from the public internet.
Cost Monitoring: Serverless is cheap until you have a Recursive Loop bug that calls a function 1 million times in a second! Set "Budget Alerts" immediately.

Serverless is the "Agility" of the modern cloud. By mastering the event-driven triggers and the discipline of stateless design, you gain the ability to build global applications that scale from zero to millions of users with zero infrastructure maintenance. You graduate from "Managing servers" to "Architecting Value."

Part of the Architecture Masterclass — engineering the agility.