구독 필터링과 확장

A naive subscription pushes every event to every subscriber. But a user watching order #42 does not care about order #99.

Filtering ensures each subscriber only receives the events relevant to them.

Subscriptions can take arguments just like queries. A client passes the ID it cares about, and the server uses it to filter the stream.

Spring for GraphQL represents a subscription as a Reactor Flux, an asynchronous stream of items. Filtering is just stream operations applied to that Flux.

Apply .filter() to the publisher so only matching events flow to the subscriber.

Use a Reactor Sinks.Many as a hub. Your service emits events into it, and every subscription builds a filtered view of its stream.

When your business logic changes an order, push it into the sink so all matching subscribers are notified.

An in-memory sink only knows about events on its own JVM. With multiple Spring Boot instances behind a load balancer, an event emitted on instance A never reaches subscribers connected to instance B.

Route events through an external broker like Redis Pub/Sub or Kafka. Every instance publishes to and subscribes from the broker, so all instances see all events.

Subscribe to a Redis channel and feed incoming messages into the same Flux your GraphQL subscription exposes, unifying local and remote events.

Slow clients can fall behind. Use a bounded buffer or drop strategy, and ensure resources are released when a client disconnects so memory does not leak.

Keep subscriptions efficient:

• Filter on the server, never push everything
• Use an external broker to scale across instances
• Handle backpressure for slow consumers
• Clean up on disconnect to avoid leaks

You scaled real-time subscriptions:

• Filter streams with .filter() using subscription arguments
• Use a Sinks.Many hub to broadcast events
• Route through Redis or Kafka to scale across instances
• Manage backpressure and clean up on disconnect

Filtered, distributed subscriptions deliver the right data at scale.