We never planned to build a memcached client. But every existing option became the bottleneck in our stack. Gateway request deduplication demanded a client that could handle real production traffic at scale. Nothing out there could keep up. When something sits this close to the hot path, I expect three things: strict opaque-token verification on every response, zero runtime dependencies beyond node:net, and real-world tests against memcached servers with authentication and TLS. This client delivers on all three. What’s the slowest link in your stack that everyone ignores?

Here’s a lesson from @matteocollina deep dive into our memcached client: A single pipelined connection outperformed a ten-connection pool from legacy @nodejs clients. Same server, same loopback, same Node version. 💡 The result? Our approach delivered triple the throughput of the fastest alternative. Why did the old clients need connection pools? They couldn’t pipeline efficiently. With a smarter parser, you unlock performance: pipeline on a single connection, parse by length for speed, and merge writes for efficiency. No extra cost, just better engineering. Pooling still matters when you need to handle large values that could block a pipelined connection. That’s what poolSize is for. But let’s be clear: pooling should solve real scaling problems, not compensate for slow parsing. How many connections does your busiest cache client open, and why?

Can’t wait to join this wonderful conference! I will be talking about @workflowsdk being the most natural foundation for agents like @eve…but…with a twist ;-)