In contrast with Flux, the Mono type defines a stream that can produce at most one element and can be described by the following formula:

onNext x 0..1 [onError | onComplete]

The distinction between Flux and Mono allows us to not only introduce additional meaning to the method signatures, but also enables more efficient internal implementation of Mono due to skipping redundant buffers and costly synchronizations.

Mono<T> may be useful in cases when an application API returns one element at most. Consequently, it can easily replace CompletableFuture<T>, giving a pretty similar semantic. Of course, these two types have some small semantic differences—CompletableFuture, unlike Mono, cannot complete normally without emitting a value. Also, CompletableFuture starts processing immediately, while Mono does nothing until a subscriber appears. The benefit of the Mono type lies in providing plenty of reactive operators and the ability to be flawlessly incorporated into a bigger reactive workflow.

Also, Mono can be used when it is required to notify a client about a finished action. In such cases, we may return the Mono<Void>  type and signal onComplete() when processing is done or onError() in the event of failure. In such a scenario, we don't return any data but signal a notification, which in turn may be used as a trigger for further computation.

Mono and Flux are not detached types and can easily be "transformed" into each other. For example, Flux<T>.collectList() returns Mono<List<T>> and Mono<T>.flux() returns Flux<T>. In addition, the library is smart enough to optimize some transformations that do not change the semantic. For example, let's consider the following transformation (Mono -> Flux -> Mono):

Mono.from(Flux.from(mono))

When calling the preceding code, it returns the original mono instance, as this is conceptually a no-ops conversion.