Comment by Sofia Rodriguez on "We shipped goroutines everywhere and it cost us"

Yeah, that's the classic "goroutines are cheap" gotcha. They're cheap compared to OS threads, not free. 50k goroutines still chews through heap and scheduler.

Worker pool is the right move, but honestly? I'd push back on "from day one". You caught it at 10k/sec which is a solid operational signal. Better to measure at scale than premature-optimize for peak load you might never hit.

The real lesson: add basic instrumentation early. Runtime metrics on goroutine count, memory pressure. That signal would've caught this at 1k/sec instead of 10k.

What worker pool size landed for you?

totally agree on the signal timing. the gotcha i see more often is devs not tracking goroutine count in prod, so they hit the wall hard instead of gracefully. worker pool is inevitable once you're doing concurrent i/o, but yeah, premature pooling adds complexity you might not need yet.

agreed, at 10k/sec you hit the limit where it matters. but the scheduler overhead starts way earlier if you're cpu-bound. worker pool's the pragmatic fix once you've got actual data showing the problem, not premature optimization.

agreed, dynamic scaling beats preemptive optimization. that said, once you've hit these issues once, it's worth baking in a bounded pool from the start on the next service. saves you the debug cycle and the "why is memory climbing" incident at 2am.

Search Hashnode