Highly concurrent in-memory counter in GoLang

Summary

An overloaded database faced heavy traffic from campaign usage tracking, motivating an in-memory counter rather than an immediate SQL-to-NoSQL migration. Because exact counts were not required, increments could be cached in the application server and flushed periodically to reduce database queries and CPU use. The implementation uses Go’s Sync.Map, with LoadOrStore and CompareAndSwap for concurrent increments, plus LoadAndDelete to atomically remove values for asynchronous persistence; the source notes a fresh-map swap as an alternative locking optimization. On an Apple M4 Pro, the 2,000-key benchmark reported 53 ns/op and 1 billion operations per 60 seconds, versus 160 ns/op and 466 million operations for a Mutex-protected map, but Sync.Map used 88 B/op and four allocations. In production, update queries fell from 140 QPS to 45 QPS, master CPU from 35% to 18%, and replica CPU from 19% to 12%.

Takeaways

1. 1

   Sync.Map measured 53 ns/op and 1 billion operations per 60 seconds for 2,000 keys, compared with 160 ns/op and 466 million operations for a Mutex-protected map.

2. 2

   The Sync.Map benchmark used 88 B/op and four allocations, while the Mutex approach used 0 B/op and zero allocations.

3. 3

   Production results included a reduction in tracking updates from 140 QPS to 45 QPS, master database CPU from 35% to 18%, and replica CPU from 19% to 12%.