One client opens a GraphQL WebSocket and starts hundreds of subscriptions — which limits stop it?

## Why the usual limits do not see this A GraphQL API's abuse controls are almost all shaped around the request/response endpoint, and every one of them has a blind spot for subscriptions. **Rate limiting counts requests.** A subscriber makes one connection attempt and then sends operations as messages on an already-open socket. From the perspective of anything counting HTTP requests per minute, an abusive subscriber is quieter than a normal user. **Cost limiting scores a document once.** When a subscription operation arrives the limiter can score its selection set exactly as it would a query. But the true cost is that score multiplied by the number of events, multiplied by the lifetime of the stream. A document scoring 40 points is trivial as a query and enormous as a subscription that fires 4,300 times an hour. **Deadlines do not apply.** A subscription is designed to outlive any wall-clock budget, so the per-operation deadline that protects the query endpoint has nothing sensible to say here. The consequence is that a server can be perfectly hardened for queries and completely open to a client that opens one socket and starts subscribing. ## Count the units the abuse actually uses Four countable resources, each needing its own cap. **Active subscriptions per connection.** The subprotocols let a client run many independent streams over one socket, each with its own identifier, and they specify no limit. Twenty is a generous ceiling for a real user interface; a warehouse operations dashboard watching every aisle might legitimately want 47 and should be made to justify it. Enforce at subscribe time, before the stream starts. ``` onSubscribe(connection, subscriptionId, document): if connection.activeSubscriptions.size() >= 20: terminateSubscription(subscriptionId, "subscription limit reached") return if connection.hasEquivalent(document): terminateSubscription(subscriptionId, "duplicate subscription") return connection.activeSubscriptions.add(subscriptionId, start(document)) ``` **Connections per identity.** A per-connection cap alone is defeated in the obvious way: open more connections. The counter therefore has to be keyed on the authenticated identity and shared across server instances, because a per-process counter is trivially bypassed by reconnecting until the load balancer hands you a different node. This is the cap people most often forget to make distributed. **Duplicate streams.** The same subscription document with the same variables, started five times under five identifiers, costs five executions of every event. Rejecting equivalents on a connection is cheap and rarely inconveniences a legitimate client. **Event rate per stream.** A subscription on a high-churn source — every stock movement in a distribution centre — can produce thousands of payloads a minute for a client that cannot use them. A per-stream rate cap that conflates or drops intermediate events keeps one busy source from saturating one socket. ## The unread stream This is the failure that surprises people, because the client is not doing anything obviously abusive: it simply stops reading. A browser tab is backgrounded, a mobile connection degrades, a script opens sockets and never consumes them. The server keeps producing. Under the hood, the socket's flow control means the server cannot push bytes the peer is not acknowledging, so the unwritten payloads accumulate in the server's outbound buffer for that connection. Nothing in the server's own logic stops that growth. Memory per connection becomes unbounded, and because it is per connection, a few hundred stalled subscribers can exhaust a process that handles thousands of healthy ones without noticing. Three policies, and you must choose one deliberately: * **Bound and disconnect.** Cap the buffer, and when it is exceeded terminate the connection. Predictable memory, and it puts recovery in the client's hands. * **Conflate or drop.** Keep only the latest payload per stream, or drop intermediate ones. This changes the API's contract — the client can no longer assume it sees every event — so it must be documented, not silently introduced. * **Degrade to a signal.** Send "something in this scope changed" and let the client refetch. Constant-size payloads, and the client resyncs from a query. **Idle connections** are the mirror image: a socket with no active subscriptions and no traffic is pure overhead. The subprotocols provide keepalive messages, so a server can distinguish a live peer from a dead one and close what is neither subscribing nor answering. ## Nothing here is specified Worth saying plainly, because interviewers probe it: the GraphQL specification says nothing about subscription limits, and the WebSocket subprotocols define message flows, not quotas. There is no standard field for "maximum subscriptions", no negotiated limit, no defined error for exceeding one. Every cap in this list is a server policy you implement and document. ## What to measure You cannot cap what you do not count. Track open connections per identity, active subscriptions per connection as a distribution rather than a mean, events emitted versus events actually delivered — the gap is your dropped or buffered volume — and the high-water mark of outbound buffers. The first sign of abuse is almost always a long tail in subscriptions-per-connection, visible long before memory becomes a page.