Eli Bendersky

This part of a series on concurrent servers shows how Go handles the problem: launch one cheap, M:N-scheduled goroutine per client, avoiding async/await since the runtime already uses epoll for I/O. It then covers cases where you should still bound concurrency—compute-heavy tasks, limited downstream resources, and malicious clients—via a channel-as-semaphore pattern or a worker pool. Tradeoff noted: goroutines are cheap, but unbounded concurrency can still exhaust CPUs or file descriptors.