Production serverless architecture and migration decisions

Last substantive review: August 2026.

A serverless proposal is worth reviewing when a production workflow has a measured constraint: a scheduled job misses its processing window, an integration worker consumes recurring operator time, burst traffic exceeds a downstream limit, or a small event handler cannot follow the monolith’s release cadence. The decision is not ready when the backlog says “move it to Lambda” but omits the event contract, retry behavior, latency budget, workload evidence, and rollback path.

That is an architecture and migration decision. Horizon Labs uses a $150–200 per hour senior-specialist lane when an established product needs an engineer to model the workload, expose managed-service constraints, build a bounded production path, and hand it back with operating evidence. Serverless may be the answer for one workflow and the wrong answer for the next. The useful deliverable is a reversible decision, not a slogan about removing servers.

Give this page one job

This guide owns the production serverless architecture and migration decision: event boundaries, state, delivery semantics, concurrency, initialization behavior, observability, security, cost envelope, testing, staged adoption, rollback, and exit triggers. Horizon’s microservices architecture guide owns service decomposition. The AWS CI/CD guide owns pipeline implementation. The disaster-recovery guide owns broader recovery planning.

“Serverless” here means an application relies on managed execution and event services while the provider operates more of the underlying capacity and runtime infrastructure. The team still owns code, data, identity, event contracts, configuration, observability, release decisions, and the behavior of every dependency. Managed does not mean unbounded or operationally invisible.

Start with a workload record, not a provider diagram

Choose one candidate workflow and capture a representative period of evidence. Do not use an average request rate where bursts matter. A useful workload record includes:

Use measured values and ranges, then state the missing data. If production has no correlation IDs or duration distribution, improving instrumentation may be the first migration task. This resembles the evidence-first approach in Horizon’s technical due-diligence guide: the architecture claim is only as useful as the records that support it.

Know which workloads deserve a pilot

A bounded event handler, scheduled job, webhook adapter, file transformation, notification fan-out, or new asynchronous workflow can be a useful pilot because the trigger and result can be named. A synchronous API can also fit when its latency budget, dependency behavior, and concurrency limits are measured. None of those categories is an automatic yes.

Be cautious when work requires a long-lived process, specialized hardware, very large local state, tight coordination across many writes, a protocol that assumes persistent connections, or a stable baseline where another runtime is easier for the team to operate. Also check provider quotas, supported runtimes, network behavior, deployment unit, and regional availability. The AWS Serverless Applications Lens offers provider-specific architecture questions, while Microsoft’s Azure Functions best practices explains how hosting plan, storage, function grouping, triggers, connections, deployment, and monitoring affect an Azure implementation.

The decision record should compare at least one credible alternative, such as a containerized worker, managed job, queue consumer in the existing application, or database-native schedule. Record why the pilot is bounded, what evidence would support expansion, and what observation would stop it.

Design the event contract before the function

An event needs a stable type, version, producer, event ID, business correlation ID, occurrence time, subject, and schema. Decide whether the payload carries a snapshot or a reference to authoritative state. If consumers will read current state, document what happens when that state changes between publication and processing. If the event carries data, document classification, retention, and compatibility expectations.

Version for consumer safety. Additive changes are not harmless when a strict parser rejects unknown fields, and removing a field is not safe because the producer no longer uses it. Keep contract tests for active producer-consumer pairs. During a migration, dual publication may be useful, but only when each path has its own metrics and duplicates cannot create two business effects.

Event-driven work needs a durable business outcome, not merely a successful invocation. Store the operation ID, input version, decision, side effects, and completion state where the workflow can find them after a retry. If a customer-facing process becomes asynchronous, expose a status model and expiry rather than leaving the UI to infer completion from silence.

Assume duplicate delivery and partial work

For stream and queue event sources, AWS documents that Lambda event source mappings process each event at least once and duplicates can occur. Other services have their own semantics. Read the documentation for the actual trigger and design the business operation to tolerate the documented delivery behavior.

Idempotency is not “catch the same HTTP request twice.” Choose a key tied to the business effect, such as invoice ID plus transition, file version plus transformation, or external event ID plus handler version. Claim or read that key in durable storage before the side effect, make conflicting attempts return the stored result or a controlled in-progress state, and retain the record for the replay window. AWS’s Lambda best-practices documentation recommends idempotent code and notes that duplicate records can occur.

Test interruption between every meaningful step: after the database write but before acknowledgment, after an external API accepts the request but before the response is stored, and halfway through a batch. Decide whether to retry the whole event, only failed records, compensate a completed side effect, or route the item for operator review. A dead-letter destination without an owner and replay procedure is storage, not recovery.

Put concurrency behind the downstream limit

Managed functions can start work faster than a database, vendor API, or legacy service can accept it. Model maximum safe concurrency from downstream connections, requests per second, transaction duration, account-level quotas, and other workloads sharing the same pool. Buffer bursts with a queue when the business process can be asynchronous. Set batch size, visibility or lock duration, retry delay, and maximum attempts from observed processing behavior.

AWS distinguishes reserved concurrency, which sets aside and caps concurrency for a function, from provisioned concurrency, which pre-initializes environments and adds a separate charge. The current Lambda concurrency documentation also describes regional quotas and scaling behavior. Treat those numbers as provider settings to verify in the target account and region, not timeless application constants.

Run a load test that includes the downstream system. A function-only benchmark can look healthy while connection pools exhaust or a vendor throttles every retry. Acceptance evidence should show queue depth, age of oldest item, active concurrency, throttles, dependency errors, completion rate, and recovery after the test load stops. If the queue cannot drain inside the business window, the architecture or limit needs another decision.

Measure initialization inside the real latency budget

Cold and warm execution paths differ by provider, runtime, package, network setup, configuration, and current capacity. Measure both in the deployed environment. Record percentiles and the conditions under which the sample was taken; do not publish one average as a universal property of serverless.

Reduce initialization work before buying a mitigation. Remove unused dependencies, initialize clients deliberately, keep network calls out of module startup where practical, and compare package and runtime choices. Google’s Cloud Run functions best-practices guide discusses cold starts, idempotency, global-scope initialization, temporary files, concurrency, and local testing in its platform context.

If a synchronous path still misses its stated budget, test the provider’s pre-initialization option, an asynchronous design, or another runtime. Include the added capacity charge and operating behavior in the decision. A background workflow may tolerate initialization that an interactive checkout does not. The product requirement decides; “serverless is fast” and “serverless is slow” are both too broad to be useful.

Keep state and multi-step work explicit

Function instances are disposable execution contexts. Durable business state belongs in a database, object store, queue, workflow engine, or another system with declared consistency and recovery behavior. Do not rely on process memory or temporary storage to carry an operation across invocations.

For a multi-step workflow, name the state machine: accepted, validated, waiting on dependency, applied, failed for retry, and sent for review may be relevant. Persist transitions with event and correlation IDs. Avoid holding a database transaction open across a network call. Commit local intent, call the dependency through a retryable boundary, and apply the response only if the stored version still permits it.

When the migration touches webhooks or third-party events, reuse the reconciliation principles in Horizon’s webhook and API reconciliation guide: preserve raw references, normalize provider state, deduplicate, compare expected and observed outcomes, and give operators a bounded replay action. That page owns marketplace cutover; this one applies the event discipline to a serverless migration.

Design observability around one business operation

Count invocations, errors, duration, concurrency, queue depth, throttles, and initialization, but do not stop there. Trace one business operation across trigger, function, queue, database, external API, and result. Include event ID, correlation ID, function and contract version, attempt, outcome, and dependency classification. Keep credentials and unnecessary customer data out of telemetry.

The OpenTelemetry specification defines common concepts for traces, metrics, logs, resources, and context propagation. Whether the team uses OpenTelemetry directly or a provider-native tool, the acceptance test is operational: an engineer can find a failed operation, see each attempt, identify the blocking dependency, and perform the documented next action.

Create alerts from the business tolerance: oldest item nearing its processing window, retries rising without completions, a dead-letter route receiving events, an external dependency throttling, or the cost envelope departing from the reviewed workload. Each alert needs an owner, runbook, and test event. A dashboard that nobody has exercised is weak handoff evidence.

Model cost with the workload, not a headline

A serverless cost model should include function requests and duration, memory or CPU allocation, provisioned capacity, API gateway, queues and workflows, storage, database operations, network transfer, logs and traces, build and artifact storage, support plan, and engineering time for the managed-service topology. Use provider calculators with the target region and current prices, then compare estimates with a replay or bounded production pilot.

Model normal, burst, replay, and failure cases. A poison message that retries thousands of times, verbose logs, cross-region transfer, or provisioned capacity can move the result. So can a container platform the company already operates well. Record the assumptions and set review triggers such as a change in invocation mix, duration, log volume, baseline utilization, or provider pricing. This guide makes no claim that serverless is always less expensive.

Track cost per completed business operation where possible, not only per invocation. Ten function calls and three queue transitions may support one document conversion. A retry storm may increase infrastructure charges without increasing completed work. The business-operation denominator makes the architecture comparable with the existing system.

Test locally, then test managed behavior in the cloud

Local tools shorten the code feedback loop. AWS documents that SAM CLI local commands can invoke functions and run an API locally. That does not reproduce every identity policy, service quota, network path, retry schedule, event-source mapping, or initialization condition of the deployed platform.

Build a test ladder: pure business-logic tests; contract tests for events and dependencies; local function invocation; integration tests against disposable managed resources; a staging replay with representative payloads; and a bounded production canary. Pin infrastructure and runtime configuration in version control. Generate synthetic sensitive values for tests and keep real production data out unless a reviewed process explicitly permits it.

At minimum, exercise duplicate events, out-of-order delivery, partial-batch failure, timeout, malformed payload, dependency throttle, permission denial, concurrency cap, cold path, log redaction, dead-letter handling, and replay. Acceptance is not “the function returned 200.” It is the business state, side effect, telemetry, and operator action matching the contract under each path.

Migrate one seam with a reversible release

Begin at a seam where the current system already has an input and output contract. Add correlation and outcome records to the existing path before replacing it. Build the new function behind a versioned adapter, queue, route, or event subscription. Then replay recorded or synthetic inputs and compare business outcomes.

During rollout, run the new path in shadow mode and suppress writes when side effects allow it. Where shadowing cannot prove the behavior, route a bounded cohort, event type, tenant, or percentage. Watch outcome parity, duplicates, queue age, dependency errors, initialization, operator workload, and cost per completed operation. Set the observation period from event frequency and business cycles rather than an arbitrary number of days.

The rollback plan needs more than “redeploy the monolith.” Preserve the old consumer until the compatibility window closes; retain events long enough for replay; keep schemas backward-readable; prevent old and new paths from applying the same effect; and document how to stop new invocation. On AWS, reserved concurrency set to zero can throttle a function while the code is corrected, as noted in the Lambda best-practices documentation, but routing, queued events, and partially completed work still need explicit handling.

If the canary fails, stop new work, classify in-flight items, reconcile completed effects, and restore the prior route. Keep the migration record open with the observed evidence. Do not erase the failed path from dashboards; it contains the information needed for the next decision.

Write exit triggers before the architecture becomes identity

Serverless remains a runtime choice, not a company philosophy. Define observations that prompt a re-evaluation: sustained baseline workload changes the cost comparison; initialization misses a user-facing budget after tested mitigations; provider limits constrain the business process; local and cloud feedback loops slow delivery; an unsupported runtime or regional requirement appears; or the topology costs more to understand than a consolidated service.

An exit may move one function to a container, combine several functions behind a service boundary, change a workflow engine, or return logic to the existing application. Keep business logic separated from event adapters and provider SDKs where that boundary is useful. Version events, export infrastructure configuration, and preserve replayable tests. Horizon’s guide to technical debt explains why hidden ownership and deferred decisions matter; this serverless record turns those concerns into named triggers.

Bring in a specialist when duplicate delivery can move money or inventory, concurrency can overwhelm a critical dependency, the workflow crosses several managed services, or the team has no credible rollback. If that is the backlog in front of you, contact Horizon Labs. The first session should use one real workflow, its traffic and failure evidence, the provider constraints, and the business decision that must become reversible.

Frequently asked questions

Is serverless architecture the same as microservices?

No. Microservices describe service boundaries and ownership; serverless describes an execution and managed-service model. A function can be part of a modular monolith, one microservice, or an event-processing pipeline. Decide the business boundary first, then choose functions, containers, or another runtime from workload and operating evidence.

Should an established company migrate an entire monolith to serverless?

Usually not as a first move. Select one bounded workflow with a clear trigger, state boundary, owner, and fallback. Good candidates often include scheduled work, asynchronous document processing, integration adapters, or a new API operation. The pilot should test event semantics, downstream limits, observability, deployment, and unit economics before the team expands the pattern.

How should serverless functions handle duplicate events?

Assume a relevant event may be delivered or processed more than once. Give the business operation a stable idempotency key, store the result or claimed state durably, make side effects conditional on that state, and test duplicate and partial-batch paths. The right storage and retention period depend on the event source and how long a replay can occur.

How do we decide whether cold starts are acceptable?

Measure the deployed cold and warm paths with the chosen runtime, package, network, region, and hosting configuration. Compare the distribution with the user or machine workflow’s stated latency budget, then test available mitigations and their operating cost. A generic benchmark cannot decide whether initialization time matters to your request path.

When does a serverless migration need a senior specialist?

Senior help is useful when the candidate workflow crosses queues, databases, identity boundaries, or third-party APIs; when duplicate delivery or concurrency can change money or inventory; when downstream systems have strict limits; or when the team lacks a reversible release path. A specialist should leave the product team with explicit contracts, tests, dashboards, runbooks, and exit triggers rather than a cloud diagram only one person understands.

Primary technical sources

• AWS Lambda: Best practices for working with functions
• AWS Lambda: How event source mappings process records
• AWS Lambda: Understanding function scaling and concurrency
• AWS SAM: Testing with sam local
• AWS Well-Architected: Serverless Applications Lens
• Microsoft Azure Functions best practices
• Google Cloud Run functions best practices
• OpenTelemetry specification overview