The Problem We Were Actually Solving Our treasure hunt engine was a Node.js microservice that handled player positions, loot drops, and real-time leaderboards over WebSockets. The hot path was a tight loop: // Node 18, iojs build clients . forEach (( socket ) => { socket . write ( JSON . stringify ( positionUpdate )); }); Enter fullscreen mode Exit fullscreen mode Under load, clients.forEach ballooned into a heap-allocated array of 100 kB per player, causing 100 MB/s GC pressure and 200 ms p95 latency spikes. The profiler snapshot from 0x showed 42 % of CPU time inside v8s incremental-marking phase and 1.4 GB of heap allocated for a single request batch. We could scale horizontally, but each container still burned 300 MB RSS and needed 30 % more CPU than the equivalent C++ service the infra team had benchmarked last quarter. Worse, every time the garbage collector kicked in, WebSocket heartbeats dropped and players saw a frozen map. What We Tried First (And Why It Failed) First idea: switch to Go.…