Serverless Architecture and Execution Models

Introduction

Serverless computing is a cloud delivery model in which the provider manages servers, operating systems, runtime infrastructure, scaling mechanisms, and much of the operational maintenance required to execute application code. The term does not mean that servers do not exist. Rather, servers are abstracted from the development and operations teams. Customers deploy functions, containers, workflows, or APIs and are generally charged according to resources consumed rather than according to permanently allocated virtual machines.

Serverless architecture is especially important in microservices because it enables independently deployable capabilities with elastic scaling and fine-grained operational ownership. A function can represent a small business operation, such as validating an order or resizing an image. However, serverless is not simply “small code on demand.” It is an execution model with particular constraints: stateless invocation, startup latency, bounded execution duration, concurrency limits, event-driven control flow, and provider-specific runtime behaviour.

This chapter examines the architecture and execution models of major serverless platforms, including functions, triggers, runtimes, cold starts, execution limits, concurrency, state management, managed workflows, and common design patterns.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the components and execution lifecycle of a serverless function.
2. Distinguish triggers, events, functions, runtimes, and destinations.
3. Analyse cold starts, execution limits, concurrency, and scaling behaviour.
4. Select suitable state-management and workflow techniques.
5. Compare representative serverless offerings from AWS, Microsoft Azure, and Google Cloud.
6. Design and evaluate common serverless microservice patterns.
7. Identify reliability, security, cost, governance, and ethical concerns.

1. The Serverless Architecture Model

A serverless application normally consists of several managed services rather than one product. A typical arrangement contains an API gateway or event broker, one or more functions, managed data stores, object storage, identity services, observability tools, and a workflow engine.

Figure: A general serverless architecture in which events enter through a gateway or broker and are processed by functions and managed workflows.

The principal abstraction is the function as a service (FaaS) unit. A function is deployed code plus configuration, such as its entry point, memory allocation, environment variables, permissions, timeout, and concurrency policy. It is usually invoked in response to an event or request.

Serverless has four defining characteristics:

• Provider-managed infrastructure: provisioning, patching, and much scaling are handled by the cloud provider.
• Event-oriented execution: invocation commonly begins with an HTTP request, message, schedule, file change, database event, or stream record.
• Elastic resource allocation: execution capacity can increase or decrease with demand, subject to quotas.
• Usage-based billing: charges commonly depend on invocation count, execution duration, memory or CPU allocation, request volume, and related services.

Serverless does not eliminate architecture. It moves architectural responsibility toward interface design, event contracts, resilience, security, observability, and service composition.

2. Functions, Events, Triggers, and Runtimes

A trigger is the mechanism that causes an invocation. An event is the data describing what happened or what was requested. The function is the computation that interprets the event and produces a response, side effect, or subsequent event.

Common trigger categories include:

A runtime supplies the language execution environment and provider integration. Managed runtimes commonly support languages such as Java, JavaScript/TypeScript, Python, Go, .NET, and Ruby, although availability and versions vary. Custom runtimes or container-based functions can support additional languages but may increase packaging and operational complexity.

A function handler should be designed around an explicit event contract. It should validate the event, authenticate or authorize where required, perform bounded work, emit structured logs, and return a well-defined result. Events should contain stable identifiers and schema versions. A useful event identifier permits deduplication when delivery is repeated.

Invocation lifecycle

A simplified lifecycle is:

1. The platform receives a trigger.
2. It selects or creates an execution environment.
3. The runtime and function code are initialized if the environment is new.
4. The handler receives the event and context.
5. The function executes, accesses permitted services, and returns or emits a result.
6. The environment may be retained for reuse or removed.

The function must not assume that an environment will be reused, and it must not assume that global variables are reset for every invocation. Initialization outside the handler may be reused, which is helpful for connection pools and cached configuration, but stale or unsafe mutable state can create defects.

3. Cold Starts and Performance

A cold start occurs when the provider must prepare a new execution environment before handling an invocation. It can involve selecting compute capacity, downloading code or a container image, starting the runtime, loading libraries, and running initialization code. A warm invocation reuses an already prepared environment and generally avoids most of this setup.

Cold-start latency depends on language runtime, package size, dependency loading, network configuration, container image size, encryption and secret retrieval, provider capacity, and configuration. It is not a fixed property of a language. Provider features such as provisioned capacity, minimum instances, startup optimization, and lightweight runtimes can reduce—but not always eliminate—cold starts.

For a synchronous request, a useful decomposition is:

Here, L_total is total observed latency; L_network is network latency; L_queue is waiting time; L_start is startup latency, which may be near zero for a warm invocation; L_handler is function computation time; and L_downstream is time spent awaiting databases or other services. This is a conceptual additive model, not a guarantee that every platform exposes each component independently. It is applicable when these sequential contributions can be reasonably separated.

Practical mitigation includes reducing dependencies, selecting an appropriate runtime, keeping deployment packages small, avoiding unnecessary initialization, reusing clients, using asynchronous processing where the user need not wait, and applying provisioned or minimum capacity to latency-sensitive paths. Mitigation must be tested against cost and traffic patterns rather than assumed to work universally.

4. Execution Limits, Concurrency, and Scaling

Every platform imposes limits on maximum duration, memory, temporary storage, package size, request size, concurrency, and regional capacity. Limits differ by product, region, account, plan, and trigger type; therefore, production design must consult current provider documentation rather than relying on remembered numbers.

Concurrency is the number of function invocations executing at the same time. For a stable workload, a basic operational approximation is:

where C is average concurrent executions, λ is average arrival rate in invocations per second, and t is average execution time in seconds. The units are invocations/second × seconds = invocations, interpreted as concurrent executions. This is an approximation based on Little’s Law and assumes a sufficiently stable system with a meaningful average and no severe overload. It should not be used as a capacity guarantee for bursty traffic or high-percentile planning.

For example, 40 invocations per second with an average duration of 0.25 seconds gives C ≈ 40 × 0.25 = 10 concurrent executions. If execution time rises to 2 seconds because a database slows down, the estimate becomes 80 concurrent executions. Thus downstream latency can consume concurrency even when request volume is unchanged.

Concurrency may be:

• Unreserved or shared: invocations compete for an account or service quota.
• Reserved or limited: a function receives a defined concurrency allocation, protecting other functions but potentially rejecting or delaying excess work.
• Provisioned or pre-initialized: capacity is prepared in advance to reduce startup delay.
• Batch or event-source concurrency: one invocation may process multiple records, depending on the integration.

When the platform cannot immediately execute an invocation, it may throttle, queue, retry, or reject it. The behaviour depends on the trigger. Synchronous callers may receive errors and need backoff. Asynchronous events may be retried and eventually sent to a dead-letter destination. Queue consumers may leave a message invisible temporarily and then make it available again.

Reliability implications

At-least-once delivery means a successful event may be delivered more than once. Functions should therefore be idempotent: processing the same logical event repeatedly should produce the same intended outcome. Common techniques include unique event keys, conditional writes, deduplication records, transactional state changes, and carefully designed idempotency tokens.

Retries require bounded policies. Exponential backoff can reduce pressure during transient failure, but retry storms can worsen an outage. A dead-letter queue or failure destination supports investigation and controlled replay. Poison messages—messages that repeatedly fail because of malformed data or an unhandled business condition—must be isolated rather than retried indefinitely.

5. State Management in Serverless Systems

Function instances are ephemeral and should be treated as disposable. Local memory and temporary disk can be useful during one invocation or while an environment is reused, but they are not a durable system of record.

State can be placed in several locations:

The preferred pattern is to keep functions stateless and persist state explicitly. A function may cache a database client or configuration in its execution environment, but correctness must not depend on cache presence. Distributed locks should be used cautiously; conditional writes or transactional operations are often safer.

State consistency must match the business requirement. Strong consistency may be necessary for account balances, while eventual consistency may be acceptable for search indexes or analytics projections. A serverless design should document what happens if two invocations update the same entity concurrently.

6. Managed Workflows and Orchestration

When a process contains multiple steps, retries, approvals, delays, compensation, or parallel branches, placing all logic in one long-running function is usually poor design. A managed workflow externalizes control flow into a provider-managed state machine.

Orchestration approaches include:

• Sequential orchestration: step B begins after step A succeeds.
• Parallel orchestration: independent tasks execute concurrently.
• Choice or branching: a condition selects a path.
• Retry and catch: transient faults are retried while terminal faults follow a recovery path.
• Human approval: the workflow pauses for an external decision or callback.
• Compensation: a later failure triggers actions that semantically undo earlier effects.

Orchestration makes progress visible and centralizes timeout and retry policy. Choreography, by contrast, lets services react to events without a central controller. Choreography can reduce coupling to an orchestrator but may make business flow, failure diagnosis, and ownership harder to understand.

A workflow should not be used merely to hide poor function boundaries. It should represent a meaningful business process or operational sequence. Long-running workflows require explicit handling of changed data, expired credentials, duplicate callbacks, and versioned process definitions.

Representative services include AWS Step Functions, Azure Durable Functions, and Google Cloud Workflows. Their syntax, state models, pricing, and integration breadth differ, but the architectural purpose is similar.

7. Major Cloud Platform Perspectives

The table is conceptual rather than a feature-for-feature equivalence. Product names, quotas, supported runtimes, regional availability, and billing models change. Architecture teams should compare the exact trigger semantics, retry behaviour, observability, identity model, networking, and service-level objectives required by the application.

8. Common Serverless Patterns

API-backed microservices

An API gateway routes HTTP requests to separate functions. Each function owns a bounded capability and accesses only the resources required for that capability. Authentication, authorization, validation, rate limiting, and schema versioning belong at appropriate gateway and service layers.

Event-driven integration

A producer emits an event such as OrderPlaced; multiple consumers independently update inventory, billing, notifications, and analytics. This reduces direct coupling but introduces eventual consistency, event versioning, duplicate delivery, and ordering questions.

Asynchronous work queue

An API accepts a job and returns a job identifier. A queue buffers work, and functions consume messages at a controlled rate. This pattern protects a slow downstream system and improves resilience, but users need a status or callback mechanism.

Fan-out and fan-in

One event is distributed to multiple workers, then results are combined. It is useful for image derivatives, document analysis, and independent validation. The design must define partial failure, correlation identifiers, maximum parallelism, and aggregation timeouts.

Scheduled automation

A scheduler invokes functions for reports, cleanup, compliance checks, or backups. Jobs should be idempotent because schedules can overlap or be retried.

Strangler migration

A serverless endpoint gradually replaces a capability in a legacy monolith. Traffic is shifted incrementally, while data ownership and transaction boundaries are carefully controlled. This is usually safer than a single large rewrite.

9. Applied Case: Illustrative Online Retail Order Service

Background and problem

A fictional online retailer operates a monolithic order application. Promotional events produce sharp traffic peaks. The application performs payment authorization, inventory reservation, email notification, and analytics updates in one request. During peaks, slow email and analytics calls increase response time and database contention.

Analysis

The business requires a fast customer response, durable order records, protection against duplicate payment requests, and traceability when an operation fails. Not every action must complete before the customer receives an order acknowledgement. Payment and inventory require stronger coordination than analytics and email.

Approach and solution

The retailer introduces an API gateway and an order-submission function. The function validates the request, creates an order with a client-supplied idempotency key, and writes the order to a managed database. It then emits an OrderCreated event.

A managed workflow coordinates payment authorization and inventory reservation. Each step has bounded retries for transient failures. A compensation path releases inventory if payment fails after reservation, while a payment reversal is initiated if a later business rule invalidates the order. Separate queue consumers handle email and analytics asynchronously. A dead-letter queue receives messages that exceed retry policy.

The database uses conditional writes so that two requests carrying the same idempotency key cannot create two orders. Correlation identifiers are included in logs, events, and workflow executions. Dashboards monitor latency percentiles, error rate, throttling, queue age, retry count, duplicate suppression, and downstream saturation.

Outcome

The customer-facing path becomes shorter and less sensitive to email or analytics latency. Queues absorb promotional bursts, while concurrency limits prevent uncontrolled pressure on the database. The design accepts eventual consistency for notifications and analytics but preserves explicit business rules for payment and inventory.

Learning points

1. Serverless scaling does not remove downstream capacity limits.
2. Idempotency is essential when retries and at-least-once delivery are possible.
3. Workflows should express business coordination rather than merely contain arbitrary code.
4. Asynchronous processing improves resilience only when status, failure, and replay are designed.
5. Observability must cross gateways, functions, queues, workflows, and databases.

10. Security, Governance, and Professional Practice

Each function should use a least-privilege identity with only the permissions required for its task. Secrets should be stored in a managed secret service, not embedded in source code or logs. Inputs require validation, output encoding where relevant, dependency scanning, and protection against injection and deserialization attacks.

Network controls may include private service connectivity, egress restrictions, firewall policies, and encryption in transit and at rest. However, private networking can increase startup latency and operational complexity. Security architecture must therefore balance exposure reduction with availability and performance.

Governance requires inventory of functions, owners, data classifications, dependency versions, regions, retention settings, and cost centres. Logs may contain personal or confidential data; collection should be minimised, access controlled, and retained according to legal and organisational policy. Data residency and cross-border transfer rules can affect event routing and managed-service selection.

Serverless also raises ethical concerns. Automated decisions triggered by functions should be explainable and auditable where they affect people. Excessive logging can create surveillance risks. Teams should evaluate accessibility, bias in automated classification, environmental impact of unnecessary compute, and the consequences of provider outages or vendor lock-in.

11. Limitations and Contemporary Directions

Serverless can create distributed-system complexity, fragmented observability, difficult local testing, provider-specific coupling, unpredictable cold-start latency, and challenging cost estimation during high-volume events. Fine-grained functions can also produce excessive network calls and deployment units. A container, managed application platform, or conventional service may be better when work is long-running, highly stateful, latency-sensitive with predictable load, or dependent on specialised operating-system features.

Current directions include serverless containers, stateful serverless abstractions, WebAssembly runtimes, event governance platforms, confidential computing, and improved distributed tracing. Generative AI is relevant when functions invoke model APIs for classification, summarisation, or retrieval workflows. Such systems require prompt and data governance, model-output validation, rate and cost controls, privacy review, and fallback behaviour. AI does not remove the need for deterministic business rules around payments, authorization, and compliance.

Best-Practice Checklist

• Define event schemas, ownership, versioning, and correlation identifiers.
• Keep handlers focused, bounded, observable, and idempotent.
• Treat local memory and temporary storage as non-durable.
• Measure cold and warm latency separately where useful.
• Estimate concurrency and validate it with burst and failure testing.
• Protect downstream systems with queues, backpressure, batching, and limits.
• Specify retry, timeout, dead-letter, and replay policies.
• Use least privilege, managed secrets, encryption, and dependency controls.
• Instrument traces, structured logs, metrics, and business outcomes.
• Reassess cost, portability, and operational ownership before selecting a platform.

Chapter Summary

Serverless architecture abstracts infrastructure management while exposing event-driven execution units and managed services. Functions are invoked by HTTP requests, schedules, queues, streams, storage events, or workflow transitions. Their lifecycle includes event receipt, environment preparation, runtime initialization, handler execution, and possible environment reuse. Cold starts contribute to latency, while execution limits and concurrency quotas shape capacity.

Reliable serverless systems assume ephemeral execution, use durable external state, and design for retries and at-least-once delivery. Idempotency, bounded backoff, dead-letter handling, and explicit schema governance are central practices. Managed workflows coordinate sequential, parallel, conditional, retrying, and compensating activities; choreography provides an alternative based on event reactions.

Serverless patterns include API-backed microservices, event fan-out, queues, scheduled automation, and strangler migration. The major cloud platforms provide comparable conceptual capabilities but differ in integrations, quotas, runtimes, identity, observability, and billing. Effective professional practice combines technical design with security, privacy, cost governance, regulatory awareness, and critical evaluation of when serverless is—or is not—the appropriate execution model.

Key Terms

Function as a service (FaaS): A model in which provider-managed infrastructure executes customer functions on demand.

Function: Deployable code and configuration that performs a bounded computation.

Handler: The entry-point routine called by the function runtime.

Event: Data describing a request, occurrence, or state change.

Trigger: Mechanism that initiates a function invocation.

Runtime: Language execution environment and supporting libraries used by a function.

Cold start: Startup delay incurred when a new execution environment is prepared.

Warm invocation: Invocation using an already initialized environment.

Concurrency: Number of invocations executing simultaneously.

Throttling: Delaying or rejecting work when a concurrency or capacity limit is reached.

Idempotency: Property whereby repeated processing has the same intended effect as one processing.

At-least-once delivery: Delivery guarantee in which an event may be delivered one or more times.

Dead-letter queue: Destination for messages that cannot be successfully processed under the retry policy.

Orchestration: Central management of workflow steps and transitions.

Choreography: Decentralised coordination in which services react to events.

Ephemeral state: Data held in temporary execution memory or storage.

Eventual consistency: Model in which replicas may temporarily differ before converging.

Backpressure: Limiting incoming work to protect constrained components.

Provisioned capacity: Pre-prepared execution capacity intended to reduce startup latency.

Serverless container: Provider-managed execution of container workloads without customer-managed servers.

Review Questions

Short Answer Questions

1. What is the difference between a trigger and an event?
2. Why should a function not rely on local memory for durable business state?
3. Define a cold start and identify two factors that influence it.
4. What does idempotency mean in an event-driven system?
5. Name two advantages and two limitations of managed workflows.

Long Answer Questions

1. Explain the lifecycle of a serverless function from trigger receipt to environment reuse, including the effects of cold starts.
2. Compare synchronous request invocation with queue-based asynchronous invocation in terms of latency, reliability, and failure handling.
3. Discuss how concurrency limits and downstream bottlenecks interact in a serverless architecture.
4. Compare orchestration and choreography for a multi-step order-processing process.
5. Evaluate the security and governance practices required for a production serverless application.

Analytical / Application Questions

1. A service receives 120 invocations per second and each invocation takes an average of 0.5 seconds. Use C ≈ λ × t to estimate average concurrency. Explain why the result is not a complete capacity plan.
2. Design an event-driven image-processing system that creates three image sizes. Specify triggers, fan-out behaviour, state or storage choices, idempotency strategy, and failure handling.
3. A function’s response time increases sharply during a promotion, although request volume is unchanged. Analyse at least four possible causes and propose measurements or architectural changes to distinguish them.

Multiple Choice Questions with Answers

Question 1

Which statement best describes serverless computing?

A. Servers are eliminated from the physical infrastructure.

B. The provider manages much infrastructure while customers deploy code and consume managed execution.

C. Applications must run only on personal computers.

D. Every function runs continuously on a dedicated virtual machine.

Correct Answer: B. The provider manages much infrastructure while customers deploy code and consume managed execution.

Question 2

What is a cold start?

A. A database transaction that is rolled back.

B. A queue message that has expired.

C. Preparation of a new execution environment before a function handles an invocation.

D. A request rejected because of invalid authentication.

Correct Answer: C. Preparation of a new execution environment before a function handles an invocation.

Question 3

Which property is most important when a function may receive the same event more than once?

A. Idempotency

B. High graphical resolution

C. Manual server patching

D. Permanent local memory

Correct Answer: A. Idempotency

Question 4

Using C ≈ λ × t, what is the estimated average concurrency for 40 invocations per second with an average duration of 0.25 seconds?

A. 4

B. 10

C. 40

D. 160

Correct Answer: B. 10

Question 5

Which storage choice is most appropriate for durable business state in a serverless application?

A. A function’s local variable

B. Temporary memory in one execution environment

C. A managed database or durable object store selected for the data requirement

D. A runtime cache without persistence

Correct Answer: C. A managed database or durable object store selected for the data requirement

Question 6

What is a primary purpose of a dead-letter queue?

A. To store messages that repeatedly fail processing for investigation or replay

B. To eliminate all retries before processing begins

C. To provide permanent local storage to a function

D. To reduce the number of event schemas in an application

Correct Answer: A. To store messages that repeatedly fail processing for investigation or replay

Question 7

Which situation most strongly favours a managed workflow?

A. A single arithmetic operation with no failure handling

B. A multi-step process requiring retries, branching, delays, and compensation

C. A static HTML page with no backend

D. A function that must store all state only in memory

Correct Answer: B. A multi-step process requiring retries, branching, delays, and compensation

Question 8

What does backpressure accomplish in a serverless design?

A. It increases every downstream service’s speed automatically.

B. It limits incoming work to protect constrained components.

C. It guarantees exactly-once delivery.

D. It prevents all cold starts.

Correct Answer: B. It limits incoming work to protect constrained components.

Question 9

Which statement correctly distinguishes orchestration from choreography?

A. Orchestration uses a central workflow controller, while choreography coordinates through service reactions to events.

B. Orchestration cannot include retries, while choreography always includes retries.

C. Choreography requires a single central database, while orchestration forbids databases.

D. They are different names for runtime initialization.

Correct Answer: A. Orchestration uses a central workflow controller, while choreography coordinates through service reactions to events.

Question 10

Which practice best supports least-privilege security for serverless functions?

A. Give every function administrator permissions.

B. Embed credentials directly in source code.

C. Assign each function only the permissions required for its task.

D. Write secrets into application logs for debugging.

Correct Answer: C. Assign each function only the permissions required for its task.