Is it safe to retry? For most APIs the honest answer is no, not without work. Any request that can be retried will eventually be retried against a handler that already succeeded, and unless you have designed for it, every retry applies the operation again. The retries are not hypothetical. A client times out and sends the request a second time. API Gateway gives up at its integration timeout and returns a 504 while the Lambda behind it keeps running and commits the write anyway, a case I covered in Part 4 of the Rust on Lambda series. An SQS or event-source trigger redelivers a message because delivery is at-least-once by default. The common thread is that at-least-once delivery is what you get for free; exactly-once is something you build. This post is about building it with DynamoDB conditional writes. ...

Serverless is sold as a system that scales itself: you write the function, and as traffic grows AWS Lambda provisions whatever capacity it takes to keep up. That is true for the majority of workloads, and it is one of the better reasons to reach for Lambda. It is not unbounded. Lambda’s autoscaling is limited on two independent axes, and both are easy to miss until real traffic hits them: ...

Observability is the ability to understand the internal state of a system by examining its external outputs. It is a broader capability than logging, and the gap between the two becomes obvious the first time a system reaches a state nobody designed for. This is the first post in a series on observability. It covers what the term means, why logs alone leave you debugging in production, the commercial case for investing in observability, and the bar an application has to clear before you can say it has it. ...

AWS Lambda forwards everything you write to stdout into CloudWatch for free, and it keeps doing so even after your handler has returned. The moment you want richer signals than text logs, or you want to send them anywhere other than CloudWatch, that free path stops being enough: you have to push the data over the network yourself. On a function that freezes between invocations, every way of doing that trades off against one of two things. You either pay Lambda’s per-millisecond billing for the time spent waiting on a remote endpoint, or you risk dropping the telemetry entirely when the environment is suspended out from under you. This post walks the approaches from simplest to most reliable and names where each one bills you or loses signals. The problem is not specific to CloudWatch; it applies to any serverless environment that scales to zero. ...

A company’s ability to operate in its market is bounded by what its backend can absorb: how fast safe changes reach production, whether a regression is contained or systemic, whether one broken component takes the rest down, whether a change has been exercised against production-like state before users see it, and whether the team observes problems before customers do. Each maps to a category of business risk and competitive position. ...

The previous four posts (Part 1, Part 2, Part 3, Part 4) covered Rust on Lambda from cold starts to architectural fit. This one is a sibling rather than a sequel, focused on a specific AWS gotcha that bites anyone wiring an LLM behind API Gateway: HTTP API v2 does not support response streaming. The modern, recommended Gateway flavor is the wrong tool for streaming LLM tokens. The older REST API got streaming support in November 2025. If you reach for HTTP API v2 by reflex (and most “use the modern one” guides will tell you to), your token stream silently collapses into a single buffered response. ...

In Part 1, Part 2, and Part 3 I argued for Rust on Lambda and measured where the gains come from. This post draws the other edge of that fence: the shapes of work where Lambda is the wrong architectural choice, however lean the binary, and whichever language you wrote it in. The common thread across every case below is a single billing fact: Lambda charges you for wall-clock duration, including the time your handler spends waiting on IO. ...

In Part 2 I measured the cold start of a minimal Rust Lambda at 18 to 22 ms. This post breaks down what that init window is actually paying for, and which parts you can move. The short version: out of the four phases that make up a cold start, only two are under your control. The rest is AWS infrastructure that you inherit whether you like it or not. The Four Phases ...

In Part 1 I covered why Rust on AWS Lambda is worth exploring and laid out the project setup. This post measures the one number that matters most for serverless latency: cold start time. To get a clean floor measurement, I used the simplest possible endpoint with no database, no external calls, and no middleware. The Benchmark Setup The handler is a single health endpoint built with Axum and Cargo Lambda: ...