Worker pools

The interview question behind this module

You already know goroutines, channels, select, context, and sync.Mutex from the last module. This one is the interview follow-up: the reusable patterns built from those primitives. "How would you bound concurrency?" "Fan-out then fan-in?" "How do you cancel a pipeline?" "How do you find a race?" This is the material that separates "I've seen goroutines" from "I write concurrent Go."

Start with the most common one. PawWalk just finished a busy morning and has 8,000 GPS fixes to score, or 3,000 booking notifications to push. The naive move is for _, job := range jobs { go handle(job) } — one goroutine per job.

Goroutines are cheap, but the work they do is not. 8,000 goroutines all hammering the database, the notification API, or a rate-limited endpoint at once is oversubscription: you exhaust connections, get throttled, and blow memory. You wanted concurrency, not a stampede.