How we build services that scale to zero

Most services spend most of their time doing nothing. A booking system, an internal tool, a new product in its first months: for long stretches of the day, no one is using them at all.

The usual way to run a service ignores that completely. It keeps a server switched on around the clock, ready for visitors who mostly are not there, and charges you the same at 3am as it does at your busiest hour. You are paying for readiness, not for use.

We build the other way. Every service we run is designed to scale to zero.

What does scaling to zero mean?

When no one is using a service, it switches all the way off. Nothing is running, and nothing is being billed. The moment someone does use it, it switches back on, does its job, and stays on for as long as people are there. When they stop, it winds back down to nothing.

The bill follows use rather than time. A service that was busy today and quiet tomorrow costs almost nothing tomorrow, with no change needed on your side or ours. Your costs track what is actually happening, instead of what might happen.

The catch: making people wait

Switching a service off is the easy part. The part that matters is switching it back on, and doing it fast enough that no one notices it was ever off.

If a service is slow to wake up, that delay lands on a real person, right when they are trying to use it. This is what the industry calls a cold start, and it is the thing that can undo the whole idea: you have swapped a steady bill for a service that feels sluggish exactly when it counts. That is a bad trade, so it is the thing we design against.

How do we keep it fast?

Two choices do most of the work, and both are about the wake-up being invisible.

The first is where we run things. Our favourite home for this is Google Cloud Run, which scales to zero as a built-in feature: it runs a service when people are there, stands down to nothing when they are not, and brings it back automatically the instant it is needed. We get pay-for-what-you-use, with no always-on server to maintain, without having to hand-build any of it.

The second is how we build the service itself. Many of ours are compiled in a way (using a technology called GraalVM) that lets them start almost instantly rather than taking the few seconds this kind of software normally needs to warm up. It makes our build take longer, but that cost is paid once, on our side, and never reaches you or your users. What you get is a service that comes back the moment it is called.

Together, those two mean the service is genuinely off when idle and genuinely instant when needed. The cold start stops being something anyone feels.

Why we care so much about this

It comes down to what it costs you to get started.

When you are early, traffic is low and hard to predict, and the last thing you want is a bill sized for success you do not have yet. Scaling to zero means your costs stay close to nothing while you are finding your feet. Quiet weeks are cheap. A busy one is handled, and then billed for what it actually was, not paid for in advance all year round.

We would rather your costs be as low as possible early on, and then grow only alongside the traffic that justifies them. That is a deliberate choice in how we build, and we work with each client to scale with cost in mind rather than handing them something that charges for sitting idle.

It is also a taste of something bigger. The way we design our APIs is built on exactly this principle: services that cost nothing at rest and come alive the instant they are called. That is a post of its own, and it is coming.