You have a fast producer and a slow consumer. Explain how Reactor handles this, and what happens specifically with Flux.interval and Flux.create.

## Two categories of source The entire question hinges on **whether the source can honor demand**. ### Backpressure-aware (cold, generative) sources `Flux.range`, `Flux.fromIterable`, `Flux.generate`, `Flux.fromStream`, R2DBC/reactive-driver streams. These generate items lazily, one demand-batch at a time. If the consumer is slow, the source simply **doesn't generate** the next item until `request(n)` arrives. Fast-producer/slow-consumer is a non-issue: the producer's speed is gated by demand. Memory stays bounded automatically. ### Non-backpressure-aware (hot, timer, or push) sources `Flux.interval`, `Flux.create` (in push modes), broker listeners, external callbacks. These produce on **their own schedule** and physically cannot pause to match demand. Here fast-producer/slow-consumer causes **overflow**, and you must decide the policy. ## Flux.interval specifically `Flux.interval(Duration.ofMillis(1))` emits an incrementing `Long` every interval on the `Schedulers.parallel()` timer, **ignoring downstream demand**. If the consumer processes slower than the tick rate, ticks accumulate with no demand and the stream terminates with an error — Reactor throws an overflow `IllegalStateException` whose message is along the lines of *"Could not emit tick N due to lack of requests (interval doesn't support small downstream requests that replenish slower than the ticks)"*. **Fix**: attach an overflow operator, e.g. `Flux.interval(...).onBackpressureDrop()` or `.onBackpressureLatest()`, so late ticks are shed instead of blowing up. The choice depends on whether you need every tick (you usually don't) or just the latest. ## Flux.create and OverflowStrategy `Flux.create(Consumer<FluxSink<T>> emitter, FluxSink.OverflowStrategy strategy)` lets a push producer emit via `sink.next(...)`. Because the producer isn't demand-driven, you declare how to handle backpressure via **`FluxSink.OverflowStrategy`**: - `BUFFER` — buffer all signals (potentially unbounded → OOM risk). - `DROP` — drop the incoming signal when downstream can't keep up. - `LATEST` — keep only the latest signal. - `ERROR` — signal an `IllegalStateException` on overflow. - `IGNORE` — ignore downstream backpressure entirely; the producer pushes regardless, and downstream operators may then throw overflow errors. `Flux.push(...)` is the single-producer variant with the same overflow semantics. ## Flux.generate vs Flux.create `Flux.generate` is **synchronous and demand-driven** — it produces exactly one item per `request`, so it is backpressure-aware by construction. `Flux.create` is **asynchronous/multi-threaded** and push-oriented, hence the explicit overflow strategy. Choosing `generate` over `create` when you control production is often the cleanest way to get backpressure for free. ## Where thread boundaries fit in Operators like `publishOn(scheduler, prefetch)` insert a bounded queue between producer and consumer threads and request upstream in prefetch-sized batches — they participate in backpressure. But a queue only helps a **backpressure-aware** upstream; it cannot stop a timer from ticking. ## Senior gotchas - Never assume Reactor 'throttles the producer' — it only signals demand; a timer/push source that ignores demand will overflow. - Unbounded `BUFFER` (in `create` or `onBackpressureBuffer`) is the classic OOM. - `onBackpressureDrop` on `Flux.interval` is the idiomatic fix for 'interval overflow' errors. - Test with a deliberately slow consumer (e.g. `.delayElements` downstream, or `StepVerifier` with `thenAwait`) to surface overflow before production does.