Node & Deno SaaS Backend Platform

The failure nobody sees

Background work has a failure mode that foreground work does not. When a page breaks, someone is looking at it. When a queued job dies, there is no one watching — the request that triggered it succeeded long ago, the user moved on, and the only evidence is something that should have happened and did not.

That is the infrastructure users never see but feel immediately when it breaks. Nobody notices the queue working. They notice the email that never arrived, the record that never updated, the export that never appeared — and by then the cause is hours behind them in a system nobody was watching.

Predictable beats best-effort

Which is why the governing requirement was that work failing silently is worse than work failing loudly. It sounds obvious and is routinely violated, because a silent failure is the path of least resistance: a job that throws and disappears requires no design, produces no alert, and leaves no evidence. A system that fails loudly has to be built to.

The distinction that follows is between predictable and best-effort behaviour. Best-effort means a job usually runs, usually retries, and usually completes — with no defined answer for what happens when it does not. Predictable means the outcomes are enumerated: this is what a failure does, this is how many times it is attempted, this is where it ends up if it never succeeds. Queues, caching, and retry handling all had to meet that standard, because each is a place where work can be lost in a way nobody observes.

Two runtimes, three subsystems

The backend spans Node.js and Deno, which is an unusual pairing and worth stating plainly rather than glossing. Running two runtimes in one system means two dependency stories and two sets of operational assumptions, so it is a decision that has to be worth something specific rather than adopted for novelty.

The three subsystems are the ones that decide whether background work completes: the queue that holds it, the retry handling that governs what happens when an attempt fails, and the caching layer that keeps the work from being more expensive than it needs to be. They are conventionally treated as plumbing, and the constraint above is the argument for treating them as the product's reliability surface instead.

What the record actually shows

This engagement carries no system metrics — no throughput, queue depth, or job volume — and the honest thing is to say so rather than reach for something that sounds like one. The two figures on it are 57 hours billed and a 5.0 client rating, and neither describes the software. They describe the engagement: how long the work took, and how the client assessed it afterwards.

Read for what they are, they still say something. Fifty-seven hours is a bounded, completed piece of work rather than an open-ended arrangement, and a 5.0 alongside "by far the best developer I have worked with" is the client's own verdict on it. For backend infrastructure, where the visible result is the absence of problems, the person who commissioned it is often the only available witness.