Goroutines Are Cheap — Until They Aren’t

The concurrency lesson many Go engineers only learn after their service has been running for a few weeks.

syarif7 min read·Just now

The graphs looked healthy.

CPU usage was stable.
Latency hovered around 12 milliseconds.
Error rates were almost nonexistent.

At first glance, the service looked like a success.

The Go backend had been in production for about three weeks, processing thousands of requests per second. Benchmarks during development had looked excellent. The system scaled horizontally without trouble. Deployments were smooth.

Then someone noticed the memory graph.

It wasn’t spiking.

It was creeping.

Slowly.

Every few hours the memory usage climbed a little higher. After a few days, the service had doubled its footprint. A week later, Kubernetes started restarting pods.

The strange part was that nothing looked obviously wrong.

The code had no large caches.
No obvious memory leaks.
No runaway loops.

This article was originally published on Level Up Coding and is republished here under RSS syndication for informational purposes. All rights and intellectual property remain with the original author. If you are the author and wish to have this article removed, please contact us at [email protected].