The Accidental Application Runtime: when a Go service quietly becomes more than an HTTP server

The transition

A fairly ordinary Go service can gradually end up owning polling loops, schedulers, workers, shared state, and shutdown-not because anyone designed an application runtime, but because the setup code was where all the dependencies happened to meet.

I wrote about recognising that transition and making the architecture explicit.

The article

The article starts with a small 3D-print farm, takes a short detour through PX4, then builds a typed in-process backplane in Go using ordinary function signatures.

The library itself isn’t really the point. The more interesting part is separating contracts that are easy to blur together:

• calls versus messages
• streams versus current state
• durable truth versus in-memory notification

Open question

I’d be interested to hear where people think this sort of abstraction stops paying for itself, or what patterns you’ve used instead.