reactor-core/src/main/java/reactor/core/publisher/Flux.java
public final <R> Flux<R> flatMapSequential(Function<? super T, ? extends
			Publisher<? extends R>> mapper, int maxConcurrency, int prefetch) {
		return flatMapSequential(mapper, false, maxConcurrency, prefetch);
	}
public final <R> Flux<R> flatMapSequential(Function<? super T, ? extends
			Publisher<? extends R>> mapper, int maxConcurrency, int prefetch) {
		return flatMapSequential(mapper, false, maxConcurrency, prefetch);
	}
public final < R > Flux < R > flatMapSequential ( Function < ? super T , ? extends Publisher < ? extends R > > mapper , int maxConcurrency , int prefetch ) { return flatMapSequential ( mapper , false , maxConcurrency , prefetch ) ; }
Transform the elements emitted by this {@link Flux} asynchronously into Publishers,
then flatten these inner publishers into a single {@link Flux}, but merge them in
the order of their source element.
<p>
There are three dimensions to this operator that can be compared with
{@link #flatMap(Function) flatMap} and {@link #concatMap(Function) concatMap}:
<ul>
<li><b>Generation of inners and subscription</b>: this operator is eagerly
subscribing to its inners (like flatMap).</li>
<li><b>Ordering of the flattened values</b>: this operator queues elements from
late inners until all elements from earlier inners have been emitted, thus emitting
inner sequences as a whole, in an order that matches their source's order.</li>
<li><b>Interleaving</b>: this operator does not let values from different inners
interleave (similar looking result to concatMap, but due to queueing of values
that would have been interleaved otherwise).</li>
</ul>

<p>
That is to say, whenever a source element is emitted it is transformed to an inner
{@link Publisher}. However, if such an early inner takes more time to complete than
subsequent faster inners, the data from these faster inners will be queued until
the earlier inner completes, so as to maintain source ordering.

<p>
The concurrency argument allows to control how many merged {@link Publisher}
can happen in parallel. The prefetch argument allows to give an arbitrary prefetch
size to the merged {@link Publisher}.

<p>
<img class="marble" src="doc-files/marbles/flatMapSequentialWithConcurrencyAndPrefetch.svg" alt="">

@param mapper the {@link Function} to transform input sequence into N sequences {@link Publisher}
@param maxConcurrency the maximum number of in-flight inner sequences
@param prefetch the maximum in-flight elements from each inner {@link Publisher} sequence
@param <R> the merged output sequence type

@return a merged {@link Flux}, subscribing early but keeping the original ordering
Transform the elements emitted by this { @link Flux } asynchronously into Publishers then flatten these inner publishers into a single { @link Flux } but merge them in the order of their source element . <p > There are three dimensions to this operator that can be compared with { @link #flatMap ( Function ) flatMap } and { @link #concatMap ( Function ) concatMap } : <ul > <li > <b > Generation of inners and subscription< / b > : this operator is eagerly subscribing to its inners ( like flatMap ) . < / li > <li > <b > Ordering of the flattened values< / b > : this operator queues elements from late inners until all elements from earlier inners have been emitted thus emitting inner sequences as a whole in an order that matches their source s order . < / li > <li > <b > Interleaving< / b > : this operator does not let values from different inners interleave ( similar looking result to concatMap but due to queueing of values that would have been interleaved otherwise ) . < / li > < / ul >