Subscription connection limits and idle timeout handling in GraphQL over WebSocket

Recommended Concurrent Subscription Count

With Apollo Server v4’s default configuration (using the graphql‑ws library) the practical ceiling is roughly 800‑1,200 active WebSocket subscription connections per server instance. This range is based on empirical observations where memory consumption reaches 200–300 MB and GC pauses start to grow noticeably. There is no hard coded limit in the library itself; the ceiling is ultimately dictated by the operating system, Node.js event‑loop capacity, and the complexity of the subscription resolvers.

Impact of No Standardized Heartbeat

The GraphQL specification does not mandate a heartbeat mechanism. Consequently, many proxies (AWS ALB, NGINX, HAProxy) treat an idle WebSocket as dead after a configurable period—commonly 30–60 seconds. If the server or client does not exchange any frames during that window, the proxy will silently close the connection, often without notifying the application.

Should You Implement Ping/Pong?

Yes. Application‑level ping/pong frames are the most reliable way to keep a connection alive behind a load balancer that enforces an idle timeout. A safe interval is to send a ping every 20‑30 seconds and expect a pong within 10 seconds. This keeps the connection well below typical 30–60 second idle thresholds while avoiding excessive traffic.

Practical Steps for Apollo v4

• Configure the underlying graphql‑ws server to emit ping frames:

  const { createServer } = require('graphql-ws');
  const wsServer = createServer({
    schema,
    // Ping every 25 seconds
    keepAlive: 25000,
  });
  

• Ensure the client also sends pings or at least responds to server pings. Most libraries (Apollo Client, urql) handle this automatically when keepAlive is set.
• Verify the load balancer’s idle‑timeout setting. If it is 60 seconds, a 45‑second ping interval gives a 15‑second safety margin.
• Monitor open sockets and memory usage in production. In Node.js you can use process._getActiveHandles() or a Prometheus exporter to track ws connections.
• When approaching 800–1,200 connections, observe GC pause times and latency spikes. If they grow, consider scaling out or optimizing resolver logic.

Missing Diagnostic Detail

To fine‑tune the ping interval for your environment, could you confirm the current idle‑timeout value configured on your load balancer (e.g., ALB, NGINX)? Adjusting the ping period relative to that value can prevent premature disconnections without adding unnecessary traffic.