Book a call

Case study 04 — Anlytic

Letting idle resources sleep, safely

Releasing what is not being used, and bringing it back so transparently that nothing notices.

  • Hands-on engineer
  • Go
  • PostgreSQL
  • Redis

Idle

released automatically

1

route back

Safe

across replicas

The problem

Idle sources held resources open indefinitely and were billed for it. Reclaiming them is the easy half. Bringing them back is the hard one: it has to happen from any entry point, under concurrency, across replicas, without anyone seeing an error.

How it fits together

One path back from idle abcalready warm?use itone winsthe rest waitrestoredevery caller takes the same route
Callers do not each solve this. They all arrive at the same door, and only one of them does the work.

What I did

Track, then release

Activity is recorded per source. Quiet ones are marked and their resources released, while the data itself is left completely alone.

One route back

Resume is centralised behind a single call, so every kind of request behaves identically. A warm connection passes straight through and costs nothing.

One winner

When several replicas arrive at once, coordination ensures one does the work and the others wait for its result rather than repeating it.

The hard part

One route, not several. The temptation is to handle resume wherever each caller happens to need it, which produces four implementations and three of them are subtly wrong.

This releases and restores connection resources. The underlying data is never stopped or removed.

Stack

  • Go
  • PostgreSQL
  • Redis
  • Kubernetes

Written at the level the reasoning survives. Internal specifics are left out on purpose.

← All work

Next step

Got something stuck?
Let's look at it together.

Send the shape of the problem — a repo, a diagram, or three paragraphs of frustration. I'll reply with what I'd do first and what it would take.