Serverless Architecture

A cloud-native pattern that lets developers focus purely on code, without managing infrastructure

1. Overview: Serverless, an architecture that runs business logic as events and functions with no servers to manage

    flowchart LR
    A["Server provisioning,<br/>operations, patching, scaling —<br/>infrastructure burden"] --"Delegate to the cloud<br/>via FaaS/BaaS"--> B["Event-driven,<br/>function-level execution,<br/>automatic scaling"] --"Focus purely on<br/>business logic"--> C["Lower operating cost,<br/>faster development"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: A cloud-native architecture in which developers do not manage server infrastructure directly, and the cloud provider fully manages the execution environment. It combines FaaS (Function as a Service) and BaaS (Backend as a Service) to implement business logic as functions that react to events.

Characteristics: (Pay-per-use) Billed by function execution time and invocation count — no cost for idle time. (Auto-scaling) Automatically scales from 0 to thousands of instances based on request volume. (Cold start problem) The first invocation incurs container-initialization delay, mitigated with sustained load or warm-up.

2. Core Structure of Serverless Architecture

A. FaaS and BaaS Components

    flowchart TD
    subgraph R1["　"]
        direction LR
        FAAS["FaaS (Function as a Service)<br/>runs business logic as functions<br/>triggered by events<br/>AWS Lambda / Azure Functions / GCP Cloud Run"]
        BAAS["BaaS (Backend as a Service)<br/>exposes backend features —<br/>auth, DB, storage, notifications — as APIs<br/>Firebase / AWS Cognito / Supabase"]
    end
    subgraph R2["　"]
        direction LR
        APIGW["API Gateway<br/>HTTP request routing, auth,<br/>rate limiting, caching<br/>AWS API GW / Kong"]
        EVT["Event Sources<br/>triggers that invoke functions —<br/>HTTP, Queue, S3, Schedule,<br/>IoT, Stream, etc."]
    end

    style FAAS  fill:#E3F2FD,stroke:#1976D2,color:#000
    style BAAS  fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style APIGW fill:#FFF3E0,stroke:#F57C00,color:#000
    style EVT   fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none

Comparison of Service Models

Model	Scope Managed	Serverless Level	Representative Services
IaaS	Manage from the OS up	None	EC2, GCE, Azure VM
PaaS	Runtime/OS management delegated	Low	Heroku, App Engine
CaaS	Container orchestration delegated	Medium	EKS, GKE, AKS
FaaS	Entire execution environment delegated	High	Lambda, Cloud Functions
BaaS	All backend functionality provided as an API	Complete	Firebase, Supabase

B. Scalability and the Event Trigger Model

    flowchart LR
    subgraph TRIGGER["Event Trigger Types"]
        direction TB
        T1["HTTP trigger<br/>API Gateway → Lambda<br/>REST/GraphQL endpoint"]
        T2["Scheduled trigger<br/>EventBridge Cron<br/>batch/periodic processing"]
        T3["Storage trigger<br/>S3 object upload<br/>image processing/conversion"]
        T4["Message trigger<br/>SQS/Kafka message<br/>asynchronous event processing"]
    end

    FUNC["Lambda Function<br/>executes business logic<br/>auto-scaling, pay-per-use"]

    TRIGGER --> FUNC

    style TRIGGER fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style FUNC    fill:#1E3A5F,stroke:#1E3A5F,color:#fff

Cold Start Problem and Mitigation Strategies

Category	Description	Mitigation
Cause of cold start	Container-initialization delay on first invocation or scale-out	Delay of hundreds of ms to several seconds
Warm-up strategy	Keep the container active with periodic ping requests	Invoke every 5 minutes via an EventBridge schedule
Provisioned Concurrency	Reserve pre-initialized execution environments	AWS Lambda Provisioned Concurrency
Runtime optimization	Lightweight runtimes (Node.js, Python), GraalVM native builds	Use Node.js instead of the JVM, trim unnecessary packages

Suitable vs. Unsuitable Serverless Use Cases

Suitable Use Case	Unsuitable Use Case
Event-driven asynchronous processing (file upload, notifications)	Long-running tasks (typically capped at 15 minutes)
Services with highly variable traffic (marketing events)	Ultra-low-latency requirements (cold start unsuitable)
Scheduled/batch jobs	Services requiring persistent state
API backends, microservices	Services needing fixed load and predictable cost

3. Expected Benefits and Application of Serverless Architecture

Category	Key Expected Benefit	Application and Practical Use
Cost optimization	Pay only for what you use — zero cost when idle	Prioritize for irregular event traffic and scheduled batch jobs
Reduced operational burden	No need to patch, monitor, or scale servers	Small teams ship an MVP quickly without managing infrastructure
Auto-scaling	Automatically scales to thousands of instances under traffic spikes	Elastic response for seasonal or event-driven services
MSA integration	Used as an independently deployable/scalable unit per service	Implement lightweight microservices by combining API Gateway with Lambda

EDA (Event-Driven Architecture)Enterprise Architecture Overview