You have a service that fetches user profiles from a slow upstream API. A hot user's profile expires from cache. In the next 50ms, 200 requests all miss the cache and stampede the upstream. You just turned one cache miss into 200 duplicate fetches — burning latency, quota, and money on identical work.

Singleflight (popularized by Go's golang.org/x/sync/singleflight) solves this: when N goroutines ask for the same key at the same time, exactly one does the work, and the other N-1 wait for its result. It's dogpile prevention scoped to a single process — no Redis, no distributed locks, no coordination overhead.

How it works: a map keyed by the request identifier holds an in-flight call object (a promise, essentially). First caller inserts the entry and starts the fetch. Subsequent callers find the existing entry and block on its completion channel. When the fetch returns, everyone gets the same result — success or error — and the entry is deleted.

Concrete example: a GraphQL resolver that loads product details by SKU. Under load, the same SKU appears in dozens of concurrent queries. Wrap the loader:

• result, err, shared := group.Do("sku:" + id, func() { return db.LoadProduct(id) })
• The shared boolean tells you whether the result was piggybacked — useful for metrics.
• One DB query serves all concurrent callers for that SKU.

The math: if your fetch takes 100ms and you get 500 requests/second for a hot key, without singleflight you do ~50 concurrent fetches at any moment. With singleflight, you do one. Load reduction ≈ concurrent requests per key during the fetch window. Higher fanout, bigger win.

The gotchas:

• Shared failures. If the singleflight call fails, all waiters get that error. One transient network blip fails 200 requests instead of 200 independent retries. Consider DoChan with a timeout so slow leaders don't hold everyone hostage.
• Cancellation contagion. If the leader's context is cancelled mid-flight, followers may see a cancellation error they didn't cause. Detach the leader's context from any single caller.
• Wrong scope. Singleflight only dedupes within one process. Behind a load balancer with 20 pods, you still get 20 upstream calls per stampede. For cross-process dedup, you need a distributed lock or a shared cache with proper locking.
• Key design matters. Include every input that affects the result. "user:123" is wrong if the fetch varies by locale — use "user:123:en-US".

Singleflight is one of those 30-line patterns that pays for itself the first time a hot key expires under load. Reach for it whenever your read path has expensive, idempotent, keyable work behind it.