Serverless, Edge, and WASM Debt

Why Serverless Debt Behaves Differently

Cold Starts and the Workarounds That Became Permanent

A cold start is the latency of creating a fresh execution environment: downloading the package, starting the runtime, and running your module-level initialisation code. The platform contribution is largely out of your hands. The part you own -- initialisation -- is where the debt lives, and it is usually the larger half.

The canonical mistake is doing work at module scope that only some invocations need, then paying for it on every cold start:

// The version that grew organically. Every one of these runs on every cold start,
// including for the health-check path that needs none of them.
const AWS = require('aws-sdk');                 // whole SDK, all services
const stripe = require('stripe')(process.env.STRIPE_KEY);
const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient();              // opens a connection at import time
const config = await loadConfigFromParameterStore();  // a network round trip
const templates = compileAllEmailTemplates();   // CPU, for a handler that rarely sends email

exports.handler = async (event) => {
    if (event.rawPath === '/health') return { statusCode: 200 };  // paid for all of it anyway
    // ...
};

The fix is not exotic. Import only what you use, defer expensive construction until first actual use, and cache it across invocations in the module scope so warm requests pay nothing:

// Import the one client you need, not the whole SDK.
import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';

let _s3, _stripe, _config;

const s3 = () => (_s3 ??= new S3Client({}));
const stripe = async () => (_stripe ??= new (await import('stripe')).default(process.env.STRIPE_KEY));
const config = async () => (_config ??= await loadConfigFromParameterStore());

export const handler = async (event) => {
    if (event.rawPath === '/health') return { statusCode: 200 };   // now genuinely cheap
    const cfg = await config();      // built once per environment, reused while warm
    // ...
};

What turns a cold start into durable debt is the workaround. Somebody adds a scheduled ping every few minutes to keep environments warm. It works, so nobody revisits the initialisation code -- and now you are paying for invocations that do nothing, at a concurrency level somebody guessed at once, for every function that ever had a latency complaint. The warmer becomes load-bearing: remove it and latency regresses, so it can never be removed. Provisioned or always-ready concurrency is the paid version of the same trade, and it has the same property of quietly converting a fixable code problem into a permanent bill.

Treat warming as a temporary measure with a written expiry, and pair every warmer with a ticket to fix the initialisation it is compensating for. A warmer with no expiry date is not a mitigation, it is a subscription.

Function Sprawl: No Owner, No Shared Library, No Consistency

Deploying a function is easy enough that it never gets budgeted for, which is precisely why estates reach several hundred of them without anyone deciding to. The count is not the problem. The problem is that each function was written by whoever needed it, in whatever style they preferred, and there is no shared spine holding them together.

The most damaging inconsistency is error handling, because it is invisible until an incident. These three handlers all sit in the same estate:

// Function A: swallows the error. The queue message is deleted, the work is lost,
// the dashboard is green, and nobody will ever find out.
try { await process(event); } catch (e) { console.log('oops', e); }

// Function B: throws everything. A malformed message is retried forever,
// re-billed on every attempt, and eventually poisons the queue.
await process(event);

// Function C: the only correct one. Distinguishes retryable from permanent,
// and sends what it cannot handle somewhere a human will see it.
try {
    await process(event);
} catch (e) {
    if (e.retryable) throw e;                  // let the platform retry
    await sendToDeadLetterQueue(event, e);     // permanent failure, preserved
}

Nothing in a per-function deployment model pushes anybody towards C. There is no shared base class, no framework default, no reviewer who sees all three files in one diff. The fix is a small internal middleware package that every handler wraps itself in, so the correct behaviour is the path of least resistance:

// @acme/lambda-kit -- one package, adopted incrementally, no big-bang migration.
export const withStandards = (fn, { name }) => async (event, context) => {
    const log = logger.child({ fn: name, requestId: context.awsRequestId });
    const started = Date.now();
    try {
        const result = await fn(event, context, { log });
        metrics.timing('handler.ms', Date.now() - started, { fn: name, outcome: 'ok' });
        return result;
    } catch (err) {
        metrics.timing('handler.ms', Date.now() - started, { fn: name, outcome: 'error' });
        log.error({ err, event: redact(event) }, 'handler failed');
        if (err instanceof PermanentError) {          // never retry these
            await deadLetter(event, err);
            return;
        }
        throw err;                                    // retryable: let the platform decide
    }
};

export const handler = withStandards(myHandler, { name: 'orders-webhook' });

Alongside the library, enforce two pieces of metadata at deploy time: an owning team tag and a purpose. An untagged function is an unownable function, and unowned functions are exactly the ones still running two years after the feature they supported was retired -- invisible in the bill, invisible in the on-call rota, and the first thing an attacker finds when they enumerate your estate. A quarterly sweep for functions with no invocations and no owner is one of the cheapest cleanups available in this whole space.

The Adapter Boundary That Costs Almost Nothing

You will not avoid vendor lock-in, and chasing full portability is usually a waste of a quarter. What you can do cheaply is confine the vendor to a boundary, so that the logic worth keeping is testable in isolation and the migration surface is one file per trigger type rather than every file.

// adapters/http.js -- the ONLY file that knows what an API Gateway event looks like.
export const fromHttpEvent = (event) => ({
    method:  event.requestContext.http.method,
    path:    event.rawPath,
    query:   event.queryStringParameters ?? {},
    headers: event.headers,
    body:    event.isBase64Encoded
                ? JSON.parse(Buffer.from(event.body, 'base64').toString())
                : JSON.parse(event.body ?? 'null'),
    // Identity is normalised here too. Downstream code never sees a claims blob.
    actor:   event.requestContext.authorizer?.jwt?.claims?.sub ?? null,
});

export const toHttpResponse = ({ status, body, headers = {} }) => ({
    statusCode: status,
    headers: { 'content-type': 'application/json', ...headers },
    body: JSON.stringify(body),
});

// handler.js -- vendor-free, and unit testable without any cloud emulator at all.
import { createOrder } from '../domain/orders.js';
import { fromHttpEvent, toHttpResponse } from './adapters/http.js';

export const handler = async (event) =>
    toHttpResponse(await createOrder(fromHttpEvent(event)));

The same discipline applies to your API surface generally, which is why this overlaps with API debt: an event envelope leaking into domain logic is the same defect as a database row leaking into a public response, and it has the same eventual cost.

Timeout and Payload Ceilings Shape Architecture

Platform limits are documented facts, not surprises -- but they are usually read after the design is fixed rather than before, and by then they have already shaped the system. AWS Lambda caps a function at 900 seconds, with a 6 MB payload for synchronous invocations and 1 MB for asynchronous ones, memory from 128 MB up to 10,240 MB, and a deployment package of 50 MB zipped or 250 MB unzipped. Cloudflare Workers gives each isolate 128 MB of memory, a compressed script size of 3 MB on the free plan and 10 MB on paid, and a CPU budget of 10 milliseconds per request on the free plan against a paid default of 30 seconds.

The debt is not the limit. The debt is what teams build when they hit one late. A report generator that runs slightly too long gets chunked into a self-invoking function that calls itself with a continuation token, which is a distributed loop with no supervisor, no overall timeout, and no way to know whether it finished. A payload slightly over the ceiling gets pushed to object storage with a pointer passed instead, which is a reasonable pattern that becomes an orphaned-object problem when the consumer fails and nothing cleans up.

// The pattern that appears when a job outgrows the timeout.
// It works, it ships, and it is now permanent architecture.
export const handler = async (event) => {
    const cursor = event.cursor ?? null;
    const { items, next } = await processBatch(cursor, { limit: 500 });

    if (next) {
        // Re-invoke self. No supervisor, no overall deadline, no completion signal.
        // If ONE link in this chain fails, the job stops silently, halfway done,
        // and the only evidence is an absence in a log nobody is reading.
        await lambda.invoke({
            FunctionName: process.env.AWS_LAMBDA_FUNCTION_NAME,
            InvocationType: 'Event',
            Payload: JSON.stringify({ cursor: next }),
        });
    }
    return { processed: items.length };
};

The honest response to hitting a ceiling repeatedly is to change the execution model, not to tunnel under the limit. Long-running work belongs in a container service, a batch service, or a real workflow engine with durable state and a visible completion status. Self-invocation chains and multi-stage payload smuggling are not clever workarounds; they are undocumented distributed systems built by accident, and they will be discovered during an incident by somebody who has never seen them before.

State Machines That Became Unreadable

Managed orchestration solves a genuine problem: durable state across steps that outlive any single function. AWS Step Functions Standard workflows can run for up to a year, with a state machine definition capped at 1 MB and state input and output at 256 KiB. Those are generous numbers, and generous numbers are how you end up with a definition that has grown past what anyone can hold in their head.

The debt has a specific shape. Business logic migrates out of tested code and into the definition, where it is expressed in JSON path conditions, retry policies, and choice states -- none of which have a unit test, a type checker, or a code reviewer who reads them carefully:

{
  "Comment": "Order fulfilment. Grew from 4 states to 60 over three years.",
  "States": {
    "CheckEligibility": {
      "Type": "Choice",
      "Choices": [
        {
          "And": [
            { "Variable": "$.order.total",  "NumericGreaterThan": 500 },
            { "Variable": "$.customer.tier","StringEquals": "gold" },
            { "Variable": "$.order.region", "StringEquals": "EU" }
          ],
          "Next": "ManualReview"
        }
      ],
      "Default": "AutoApprove"
    }
  }
}

That condition is a business rule about who needs manual review. It is untestable without deploying, it will not appear in any search for the words that describe it, and when it changes there is no test that fails. Nobody chose to put pricing policy in a JSON document; it arrived one small edit at a time.

Keep orchestration definitions structural: sequence, parallelism, retry, compensation, and timeouts. Push every predicate about the business into a function that can be unit tested and returns a decision the state machine merely routes on. If a definition needs a diagram to be explained, it has outgrown the format, and the next person to modify it under incident pressure will get it wrong.