Michael Cabassol

Writing

The load balancer runs my test suite

Once a system distributes across AWS, the value of unit tests drops dramatically and the need for integration and end-to-end testing grows exponentially. Unit tests still earn their keep — they are how you understand and debug the code while you are writing it. Writing them to move a coverage number is throwaway work. I have watched teams chase a magical eighty percent because someone mandated it somewhere in the business, then use AI to generate tests that pass the gate and test nothing. The result is a suite that is green, brittle, and silent about whether the system actually works — because in a distributed system, the risk lives in the seams, not the functions.

So I bake the integration tests into the service itself, behind a health endpoint. The load balancer hits it and runs them continuously. Not a liveness ping — a real test, exercising real dependencies, on the deployed system, all day.

engraving of two steam locomotives with loaded tenders facing each other nose to nose on a riveted iron truss bridge span, both venting heavy smoke, several period railway workers on the deck for scale, the span resting on stone piers
Fig. 01 — Load test

The rest is observability, and the point of observability is time to root cause. I built a scraping fleet that scaled to five thousand concurrent Lambdas — three to four million pages per site, scanned in under two hours. With that many requests in flight, sampling ten percent of logs and guesstimating makes isolating a bug nearly impossible — and the full stream arrives as gigabytes of logs per second that most platforms will charge a fortune to ingest.

What made it tractable: one JSON log per HTTP request. Middleware consolidates every component’s entries into a single log that knows its context — which Lambda it ran from, what environment, what build, what version — and a request ID rides every call between services, so logs merge across the whole system. That is tracing. X-Ray looks great and is cost-prohibitive at tens of millions of requests; this gets you the same information without the bill. While a feature was new we logged absolutely everything; once confidence built, full traces only on warns and errors. That saves real cost, and it causes headaches the day you need to research what was processed.

One HTTP request, across every service it touches 01 02 03 service emits entries service emits entries service emits entries request id request id middleware consolidates every component's entries one JSON log per HTTP request request id lambda environment build version logs merge across the whole system · that is tracing
Fig. 02 — One request ID on every call between services, and middleware folding each component's entries into a single JSON log line — that identifier is what merges the logs across the whole system, with no tracing bill behind it.

Fig. 02 · pinch or scroll to zoom · drag to pan

Then everything — logs and metrics — goes into one place where it can be correlated: Datadog, or SigNoz on ClickHouse if you want open source.

A high coverage number tells you the functions work. It does not tell you the system works. I don’t sell coverage. I ship systems that test themselves continuously in production and log so that when something fails, the answer is already written down.

More writing

I don’t hire on certifications
Why the résumé I read is the systems catalog, not the badge list
Newer · Aug 2026

Start

Tell me what’s stuck

I’ll tell you in about a day whether I’m the right person. The first conversation is fit, not a free architecture review.