2 posts tagged with "operations"

Every Go tutorial ends the same way: log.Fatal(app.Listen(":3000")). The server starts, the tutorial is done. Nobody talks about what happens when the server stops.

Here is what happens: a deploy rolls out, the process gets SIGTERM, and every request that was mid-flight - a database write, a file upload, a payment confirmation - gets killed instantly. The client sees a connection reset. The database row is half-written. The payment went through but the confirmation never reached the user.

Graceful shutdown is not a nice-to-have. It is the difference between "the deploy went fine" and "we lost three transactions during the rollout."

Many runtime incidents happen during transitions, not steady state.

A service is starting up, shutting down, draining workers, or flushing telemetry, and behavior is only partially defined. If your deploy process relies on conventions like "we always flush metrics before exit," but nobody enforced that in code, you get data loss during rollouts. If startup checks happen in scattered goroutines, a failing dependency might not block listen, and you serve errors for the first few seconds after deploy.

Fiber v3 hooks give that lifecycle a concrete structure. Instead of hoping everyone follows the same script, you can register pre and post handlers for startup and shutdown and make the behavior reviewable.