Course outline

01 · Getting Started6/6

02 · Variables, Types & Control Flow6/6

03 · Functions & Composite Types6/6

04 · Methods, Interfaces & Errors6/6

05 · Packages, Modules & Concurrency Intro6/6

06 · Your First Real Program6/6

07 · Testing & Debugging in Go6/6

08 · Capstone — Ship a Real Tool7/7

09 · Generics6/6

10 · Concurrency in Practice6/6

11 · Language Depth II6/6

12 · Standard Library Toolkit6/6

13 · Building Web Services6/6

14 · Working with Databases6/6

15 · Advanced Runtime & Tooling6/6

16 · Building a Terminal Dashboard with Bubble Tea5/5

17 · Closing the Loop2/2

Stage 1 · Code

Concurrency in Practice

Worker Pools

When you have far more jobs than you want running at once, a worker pool gives you controlled concurrency: enough parallelism to make progress, but with a clear upper limit.

14 min readThe Complete Go EngineerCode

Why Limit Concurrency

Suppose you need to process 10,000 images, API requests, or files. Launching 10,000 goroutines is possible, but that does not automatically mean it is wise. The real bottleneck may be a database connection pool, an external API rate limit, CPU, memory, or simply how much simultaneous work your machine can handle without becoming noisy and slow.

A worker pool is the pattern for this situation. Instead of starting one goroutine per job with no limit, you create a fixed number of workers. All workers read from the same jobs channel. That means at most that many jobs are in progress at once, no matter how long the queue becomes.

A worker pool limits in-flight work, not total work

You might still have 10,000 jobs overall. The pool only answers one question: how many are allowed to run concurrently right now? That is what protects downstream systems and your own process from being overwhelmed.

Building the Pool

The moving parts are straightforward once you see their roles clearly. The jobs channel is the queue of work to be done. Each worker goroutine loops over that channel and processes jobs one by one. A results channel carries completed outputs back. A WaitGroup tracks when all workers have exited, and only then do we close the results channel.

Goa-complete-worker-pool-with-bounded-concurrency.go

44 linesLn 1, Col 1Go

Three workers are started, so at most three jobs run at once. Closing `jobs` tells workers there will be no more input. Closing `results` happens only after `wg.Wait()` proves every worker has stopped sending.

Start a fixed number of workers up front.
Feed jobs into one shared jobs channel.
Each worker ranges over that channel until it closes.
Use a WaitGroup to know when every worker is finished.
Only the coordinating goroutine closes the results channel, and only after all sends are done.

Tracing Three Workers and Six Jobs

The exact worker-to-job mapping is nondeterministic because it depends on scheduling. That is normal. What is deterministic is the high-level behavior: no job is processed more than once, every submitted job is eventually handled, and no more than three jobs are active at a time because the pool only has three workers.

Goone-possible-run-with-three-workers-and-six-jobs.go

52 linesLn 1, Col 1Go

Your run may assign different workers to different jobs, and that is fine. The pattern is correct as long as the pool limit is honored, every job is consumed once, and channel closure happens from the coordinating side after all sends are finished.

Close from the owner side

The goroutine that sends all jobs should close jobs because it owns job production. The coordinating goroutine that waits for all workers should close results because it knows when no more results can possibly be sent.

Quiz and Practice

Quiz & Practice

Question 1 / 3

What is the main reason to use a worker pool instead of starting one goroutine per job with no limit?

Hands-On Project

Build a small worker pool that processes many numeric jobs safely, but returns one stable summary value so the harness does not care which worker handled which job.

SumSquaresWithPoolMedium

Write a function `SumSquaresWithPool(workerCount int, jobs []int) int` that uses a worker pool. Each worker should square the jobs it receives and send the squared value to a results channel. Return the sum of all squared results after every job has been processed.

Gosolution.go

Summary and Key Takeaways

Use a worker pool when you have many jobs but need a fixed upper bound on concurrent work.
All workers read from the same jobs channel, so the queue distributes work naturally.
A WaitGroup tells you when every worker is finished.
Close jobs from the sender side and close results only after all workers are done sending.
The exact worker-to-job assignment may vary, but the concurrency limit and overall correctness should not.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.