Advanced concurrency patterns in Go
You design concurrent systems that do not leak, can be cancelled and stay stable under load using errgroup, semaphores, rate limiting and atomics.
Level 401 · 16 lessons · 15 practice labs
Lessons
Structured concurrency
- errgroup: errors and cancellation together
- Fan-out and fan-in
- Bounded parallelism with a semaphore
- Goroutine leaks and catching them with goleak
- Short task: a downloader that runs at most N jobs at once
Behaviour under load
- Rate limiting: x/time/rate and the token bucket
- Backpressure: what happens when the queue is full?
- Retries and exponential backoff
- singleflight and a concurrent cache
- Short task: a limited, retrying and cancellable client
Low-level concurrency
- sync/atomic and the atomic types
- RWMutex, sync.Cond and sync.Once
- The Go memory model: the happens-before relation
- Diagnosing deadlocks with a stack dump
- Short task: repair a service with a race and a deadlock
Capstone
- Capstone: a rate-limited, cancellable job queue service
Practice labs
- Stopping on the first error with errgroup: Run three independent checks with errgroup and show the others are cancelled through the context when one fails.
- Merging several sources into one channel: Merge several producer channels into one, close the output when all sources finish and leave no sender blocked on cancellation.
- Collecting partial results and errors from fanned-out work: Fan a hundred address checks out to workers so failures do not stop the rest, results return in input order and errors come joined with errors.Join.
- Limiting concurrency with a channel semaphore: Use a buffered channel as a semaphore so at most five jobs run at once and verify the limit with a test.
- Catching a leaking goroutine with goleak: Catch with goleak the goroutine left blocked writing to an unbuffered channel after a timeout and fix it.
- A downloader that runs at most N jobs: Write a cancellable fake downloader limited with errgroup.SetLimit that stops on the first permanent error, cleans temp files and passes the leak test.
- Passing requests through a rate limiter: Apply a limit of ten requests per second with a burst of five using x/time/rate and test that Wait honours context cancellation.
- Deciding what happens when the queue is full: Make an unbounded job queue bounded, reject new work when full, count rejections and measure that memory use stays flat.
- Managing a token bucket per client: Keep a separate limiter per client, clean up unused ones after a period and show memory does not balloon with a million distinct clients.
- Retrying with growing back-off: Write a helper that retries transient errors with exponential back-off and jitter and stops at once on a permanent error.
- Preventing a cache stampede with singleflight: Ensure with singleflight that a hundred simultaneous requests for the same key make one backend call and prove it with a call counter.
- A limited, retrying and cancellable client: Write a client combining a rate limit, a retry budget and an overall deadline and show by test that no retry storm forms when the backend is down.
- sync.Once for one-time set-up: Reduce a setting reloaded on every call to a single load with sync.Once and test that concurrent first calls load once.
- Swapping settings with an atomic pointer: Use atomic.Pointer to refresh settings without locking readers and show with -race that readers never see a half-updated value.
- Diagnosing a deadlock from a stack dump: Find the lock-order conflict and the race from the goroutine dump of a stalled service and pass the load test with a consistent lock order and a sync.Cond fix.
About this course
You design concurrent systems that do not leak, can be cancelled and stay stable under load using errgroup, semaphores, rate limiting and atomics.
What you will learn
- Structured concurrency
- Behaviour under load
- Low-level concurrency
- Capstone
Prerequisites
You should have practised the topics of the same path up to level 301.
Lab environment
Lessons run in your own Kali Linux terminal that opens in the browser. Nothing to install; the lab starts clean in every lesson.
Frequently asked questions
- Is this course right for my level?
- The course is at level 401; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.