Kontrola przeciążenia i obsługa błędów w strumieniach reaktywnych

In reactive systems a producer may emit data faster than a consumer can process it. Without control this overwhelms memory. Backpressure is the mechanism that solves this.

Backpressure lets the consumer signal how much data it can handle. The producer respects this demand, sending only what was requested.

A subscriber calls request(n) to ask for n elements. The publisher emits at most that many until more are requested. Operators usually manage this for you.

The onBackpressureBuffer operator stores excess items until the consumer is ready. Beware unbounded buffers can still exhaust memory.

When you cannot keep everything, onBackpressureDrop discards extra items and onBackpressureLatest keeps only the most recent. Useful for live data where freshness beats completeness.

In Reactor an error is a terminal signal that stops the stream. Unlike exceptions you wrap in try-catch, you handle them with dedicated operators.

Use onErrorReturn to substitute a default when an error occurs, keeping the stream alive with a sensible value.

onErrorResume lets you switch to an alternative publisher when the primary fails, such as a cached source.

The retry operator resubscribes after an error. Combine with backoff to avoid hammering a struggling downstream service.

doOnError runs a side effect like logging without altering the stream, useful for observability.

A robust pipeline often logs the error, retries with backoff, and finally falls back, giving resilience under transient failures and graceful degradation under permanent ones.

You learned how backpressure controls fast producers via buffer, drop, and latest strategies, and how to handle errors with onErrorReturn, onErrorResume, retry, and doOnError for resilient reactive pipelines.