Does my channel buffer size choice hide backpressure problems, and how do I decide it?
Keep channel capacity near the worker count, let blocking propagate to the Kafka poll loop, and when consumer lag climbs grow workers, not the buffer.
Tag
Building applications and tools in Go: concurrency, error handling and the standard library. questions under this tag, answered directly.
11 answered questions carry this tag.
Keep channel capacity near the worker count, let blocking propagate to the Kafka poll loop, and when consumer lag climbs grow workers, not the buffer.
Flip `CMD` to exec form and listen with `signal.NotifyContext(..., syscall.SIGTERM)` instead of `os.Interrupt`; add tini only if the worker forks.
Move to `errgroup.WithContext` with a request-level timeout on top and thread ctx into every HTTP and DB call; an ignored ctx means no cancellation at all.
Cancellation propagates only if you pass `r.Context()` into every downstream call, leave no `context.Background()` in the chain, and use `WithoutCancel`.
Export NumGoroutine() as a metric, take a pprof goroutine dump at peak, make the spawn site behind the parked stacks honor ctx.Done(), then add goleak.
Let one tag-triggered workflow cross-compile and publish the GitHub Release while the homebrew_casks: block updates the tap; the tap needs its own PAT.
Wrap requests in a `defer recover()` middleware at the outermost layer, log the stack with the request id, return a generic 500 and emit a metric.
On SIGTERM drain the load balancer first, finish in-flight work inside the server.Shutdown(ctx) deadline, then align the grace period with that drain.
The enemy behind the pauses is allocation rate: kill the top allocator with pprof, pool the hot path with sync.Pool, and tune GOGC last, not first.
Shift payments at the gateway by 5/20/100 and validate in shadow first; the real work is splitting the tables, behind an anti-corruption layer and outbox.