The Goroutine Lie Nobody Tells You

You chose Go because goroutines are cheap.

Spawn 100k. No problem.

Then at 10k requests/second, your system gets weird.

RAM climbs. Latency spikes. GC pauses hit 500ms.

You add more servers. Nothing changes.

The problem: You’re not spawning goroutines responsibly.

Goroutines are cheap to create. Expensive to wait on.

// This looks fine but destroys your system
for user := range users {
    go process(user)  // infinite goroutines waiting on DB
}

// At 10k users, you have 10k goroutines all waiting.
// 10k × 2KB = 20MB just sitting there.
// Database is slow. They wait longer. Memory explodes.

The fix: Limit them

// Only 100 goroutines at a time
limiter := make(chan struct{}, 100)

for user := range users {
    go func(u User) {
        limiter <- struct{}{}       // acquire slot
        defer func() { <-limiter }() // release when done
        process(u)
    }(user)
}

Now: max 100 running. Queue waits. Memory stable. Problem solved.

The bigger issue: Don’t wait synchronously

// Request waits for database
result := db.Query(ctx, sql)  // request blocks 2 seconds
return result

// Request returns immediately
go func() {
    db.Query(ctx, sql)           // runs in background
    kafka.Publish("results", ...)
}()
return "processing..."  // user gets response in 10ms

Before you deploy Go, ask:

1. Can one request spawn unlimited goroutines? (Yes = you’ll crash)
2. Are you monitoring goroutine count? (No = you won’t see the spike until 3am)
3. Are requests blocking on slow calls? (Yes = redesign to async)

If you answered “yes” to any: fix it before production.

One thing to remember

Goroutines aren’t free. They’re deferred work. Bound them or pay the price.