Book a call

Case study 03 — Anlytic

Finishing a job after the user has gone

Connecting a data source when the slow part completes long after the page has closed.

  • Hands-on engineer
  • Go
  • gRPC
  • PostgreSQL

0

reliance on an open tab

Resumable

across restarts

Unattended

completion

The problem

Connecting a source runs from credentials through authentication and a first import, and only then is anything usable. That import is asynchronous and can take minutes or hours, which rules out doing the remaining work inside the request that started it.

How it fits together

Work continuing after the request ends startset upin requestrequest ends herebackground workretries, survives restartreadythe tab may be long closed by now
The visible part finishes in seconds. The rest completes on its own, whether or not anyone is still there.

What I did

Move it off the request

The slow half runs in the background from the moment setup completes, with backoff, protection against starting twice, and recovery if the process restarts.

Own the finish

When the upstream side is finally ready, the service completes the remaining setup by itself. The user returns to something already working.

Behave at the boundary

External failures are translated into something a person can act on, and outbound calls are paced to stay within limits.

The hard part

Every step had to survive a closed tab and a restart. Once you accept that nobody is watching, the work has to own its own completion, including knowing whether it already began.

Stack

  • Go
  • gRPC
  • PostgreSQL
  • React

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.