리액티브 스트림의 백프레셔 처리

A reactive WebSocket may emit market ticks faster than a client can consume them. Without control, buffers grow until memory is exhausted. This mismatch is what backpressure solves.

Backpressure is the consumer telling the producer how much it can handle. In Reactor, the subscriber requests n items; the publisher must not exceed that demand.

A reactive Flux built from a cold source naturally honors demand: nothing is produced until requested. The challenge appears with hot, time-driven sources like a price feed that emits regardless of demand.

In WebFlux a handler wires the outbound Flux into session.send. The framework subscribes and applies the transport's demand for you.

Buffer overflow items up to a limit, then take an action. Good when bursts are short.

When the consumer is slow, simply drop new items. Ideal for telemetry where only the latest values matter.

Keep only the most recent item, discarding intermediate ones. Perfect for a live dashboard that shows the current value, not the history.

Instead of dropping reactively, reduce the rate up front. sample emits the latest value at a fixed interval, smoothing a firehose into a manageable stream.

Unbounded buffers are the silent killer. Always cap buffers and choose a strategy (drop, error, latest) so a stalled client cannot consume the server's heap.

If a client repeatedly triggers drops, it may be too slow for the feed. Consider lowering its update rate, sending deltas, or closing the session with a clear status.

Match the operator to the data:

• Must-not-lose orders → buffer with a safe cap, or error
• Live metrics/prices → latest or sample
• Best-effort telemetry → drop

You tamed reactive streams:

• Backpressure aligns a fast producer with a slow consumer
• Reactor is demand-driven; hot sources need explicit handling
• buffer, drop, and latest strategies suit different data
• sample throttles a firehose at the source
• Never leave buffers unbounded; close clients that cannot keep up