go-concurrency-web
Go concurrency patterns for high-throughput web applications including worker pools, rate limiting, race detection, and safe shared state management. Use when implementing background task processing, rate limiters, or concurrent request handling.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/anderskev/go-concurrency-webGo Concurrency for Web Applications
Quick Reference
| Topic | Reference |
|---|---|
| Worker Pools & errgroup | references/worker-pools.md |
| Rate Limiting | references/rate-limiting.md |
| Race Detection & Fixes | references/race-detection.md |
Core Rules
- Goroutines are cheap but not free — each goroutine consumes ~2-8 KB of stack. Unbounded spawning under load leads to OOM.
- Always have a shutdown path — every goroutine you start must have a way to exit. Use
context.Context, channel closing, orsync.WaitGroup. - Prefer channels for communication — use channels to coordinate work between goroutines and signal completion.
- Use mutexes for state protection — when goroutines share mutable state, protect it with
sync.Mutex,sync.RWMutex, orsync/atomic. - Never spawn raw goroutines in HTTP handlers — use worker pools,
errgroup, or other bounded concurrency primitives.
Gates (check before merge or review)
Use these sequenced checks for objective pass/fail; do not replace them with “I verified mentally.”
- Race detector
- Run
go test -race ./...on packages that changed concurrent code, orgo build -racefor binaries under test. - Pass: exit code
0. If you report “no races,” attach or cite CI output / saved terminal transcript—do not assert cleanliness without that artifact.
- Run
- Bounded background work from HTTP
- Inspect handlers and middleware that start work beyond the request goroutine.
- Pass: every such path uses a bounded primitive (worker pool, buffered channel with documented capacity,
errgroupwith an explicit concurrency cap)—not unboundedgoper incoming request.
- Graceful teardown
- For processes that start long-lived goroutines, trace from shutdown signal (or test
defer) toWait()/ channel close /contextcancel for each goroutine family. - Pass: you can point to the call chain or a test that proves shutdown completes without hang (no orphan goroutines).
- For processes that start long-lived goroutines, trace from shutdown signal (or test
Worker Pool Pattern
Use worker pools for background tasks dispatched from HTTP handlers. This bounds concurrency and provides graceful shutdown.
// Worker pool for background tasks (e.g., sending emails)
type WorkerPool struct {
jobs chan Job
wg sync.WaitGroup
logger *slog.Logger
}
type Job struct {
ID string
Execute func(ctx context.Context) error
}
func NewWorkerPool(numWorkers int, queueSize int, logger *slog.Logger) *WorkerPool {
wp := &WorkerPool{
jobs: make(chan Job, queueSize),
logger: logger,
}
for i := 0; i < numWorkers; i++ {
wp.wg.Add(1)
go wp.worker(i)
}
return wp
}
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-anderskev-go-concurrency-web": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
tutorial-docs
Tutorial patterns for documentation - learning-oriented guides that teach through guided doing
fetch-pr-feedback
Fetch review comments from a PR and evaluate with receive-feedback skill
swift-testing-code-review
Reviews Swift Testing code for proper use of
rust-testing-code-review
Reviews Rust test code for unit test patterns, integration test structure, async testing, mocking approaches, and property-based testing. Covers Rust 2024 edition changes including async fn in traits for mocks,
explanation-docs
Explanation documentation patterns for understanding-oriented content - conceptual guides that explain why things work the way they do