This is trickily enough not the right thing, .async() creates an async boundary between the graph so far and the next steps, to create a separate async island for each substream you would have to do .via(Flow.reduce(...).async())

ah gotcha! I wasn't aware about this, and maybe I've been using it wrongly. I'll update the example.

@johanandren : just to confirm adding async between groupBy and flow is kind of redundant then and has no impact? wondering if it should even compile if it's redundant because it's misleading

Just groupBy().async would put the graph up to that point, so Source.range and groupBy grouping on one stream interpreter actor, and then all the downstreams and the substream merge and sink would run in another single actor. So it has impact but it does not do what we want to show here (one separate stream interpreter per substream).

@johanandren : does this diagram depict the right understanding ? before making the change I wanted to understand correctly.

I think the current example is state A and we want to show state B in the example by adding async to the flow before merging sub streams. correct?

Just doing .async after groupBy means that you end up with two interpreters/actors running the stream, one up to the .async and one after.

State B is correct, Flow.a.b.b.async adds a boundary around each materialisation of that flow

@johanandren : the image you attached is the current state right ? and State B which is correct will be done by adding async in the example as proposed by you , right?

also the materialisation of the stream happens even between the actors or only at the end of the stream?

Yes, exactly, my drawing is what happens with the current (instead of your suggested State A), State B in the diagram is the fixed Flow().async one.

The materialization, turning a stream graph/bluepring into a running stream, of the sub stream happens each time a new group-by key is seen, however, normally the sub stream is materialized into the existing running stream. The async boundary around it means materialized stream becomes a separately running stream.

Thanks for the answer @johanandren. I've now changed the example as suggested, can you please review it again?