Cold vs Hot Publishers

Cold publishers typically create an independent sequence for each subscriber, while hot publishers expose a shared, ongoing source whose emissions can be observed by multiple subscribers. The distinction matters when deciding whether each subscriber should receive its own execution or participate in shared activity.

A cold publisher does not normally produce values until a subscriber arrives, and each subscription starts its own execution of the source. For example, a cold `Flux` created from a range, file operation, or deferred computation can execute separately for every subscriber.

A hot publisher represents an ongoing source whose production is not inherently tied to an individual subscription. Multiple subscribers can observe the same source, and a subscriber that joins after an emission may not receive that earlier value. Typical examples include live events, telemetry, or a message source being broadcast to several consumers.

In Project Reactor, operators such as `share()` can turn a cold publisher into a shared stream. `publish()` exposes a `ConnectableFlux`, allowing the application to control when the shared source starts. `replay()` can additionally retain previously emitted signals so later subscribers can receive some or all of the history, depending on configuration.

The important interview distinction is behavioral rather than simply whether an object is declared as a `Flux` or `Mono`. A publisher's subscription semantics determine whether work is repeated per subscriber or shared. Operators can also change those semantics, so the source and the operators applied to it should both be considered.

Key points

• Cold publishers normally perform independent work for each subscriber.
• Hot publishers can share an ongoing source between subscribers.
• Late subscribers to a hot stream may miss earlier emissions.
• `share()` can make a cold Reactor publisher multicast and shared.
• `replay()` can preserve selected earlier signals for later subscribers.

Interview questions

What is the difference between a cold and a hot publisher?

A cold publisher normally starts its sequence separately for each subscriber. Therefore, two subscribers can cause the source operation to execute twice and each can receive the complete sequence. A hot publisher represents a shared or independently running source, so subscribers can observe the same emissions. A subscriber joining late may miss values that were already emitted.

How can you make a cold `Flux` shared in Project Reactor?

One common approach is the `share()` operator, which establishes multicast behavior over the source. Multiple overlapping subscribers can then consume the same upstream execution rather than causing separate executions. The exact lifecycle behavior matters, because sharing is tied to active subscriptions. If historical values must also be delivered to later subscribers, `replay()` is a different tool.

Why can a late subscriber miss values from a hot publisher?

A hot source can emit independently of a particular subscriber. If an event is emitted before that subscriber joins, there is no requirement for the subscriber to receive that earlier event. This is different from a cold source, where subscribing normally initiates a fresh sequence. Replay or another buffering mechanism is needed when late subscribers must receive earlier signals.

What is the practical impact of choosing cold versus hot behavior in a backend service?

The choice determines whether upstream work is duplicated or shared. A cold publisher is useful when each request needs an independent computation or subscription-specific operation. Sharing can reduce duplicated work when several consumers need the same live result, but it introduces lifecycle, timing, backpressure, and failure-sharing considerations. For state or events that must be available to late consumers, explicit replay or persistence may be more appropriate than simple sharing.