# Shared flows, broadcast channels

DevFeed: [Shared flows, broadcast channels](<https://devfeed.tech/articles/shared-flows-broadcast-channels-26027.md>)

Original publisher: [Read original article](<https://elizarov.medium.com/shared-flows-broadcast-channels-899b675e805c?source=rss-4762e889f8fc------2>)

Author: Roman Elizarov

Published: 2020-11-16T13:16:59Z

Content type: article

Language: en

Sources: [Stories by Roman Elizarov on Medium](<https://devfeed.tech/sources/stories-by-roman-elizarov-on-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [kotlin-flow](<https://devfeed.tech/topics/kotlin-flow.md>), [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [Streams](<https://devfeed.tech/topics/streams.md>)

Tags: [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [channel](<https://devfeed.tech/tags/channel.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [flow](<https://devfeed.tech/tags/flow.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-flow](<https://devfeed.tech/tags/kotlin-flow.md>), [streams](<https://devfeed.tech/tags/streams.md>), [synchronization](<https://devfeed.tech/tags/synchronization.md>)

## AI overview

This article explains why Kotlin shared flows were introduced as a replacement for broadcast channels for distributing events and state updates to multiple subscribers. It contrasts channel-based transformations with Kotlin Flow, emphasizing the synchronization costs of channels and the efficiency of flow transformations.

## Source excerpt

Photo by Davies Designs Studio on Unsplash Once upon a time coroutines were introduced to Kotlin and they were lightweight. We could launch a multitude of coroutines and we needed a way to communicate between those coroutines without running into a dreaded "mutable shared state" problem. Thus Channel was added as an inter-coroutine communication primitive. The channels are wonderful. Channels support one-to-one, one-to-many, many-to-one, and many-to-many communication between coroutines, and every value that is sent to the channel is received once. Diagram of many-to-many channel operation You cannot use channels to distribute events or state updates in a way that allows multiple subscribers to independently receive and react upon them. Thus the BroadcastChannel interface was introduced with buffered and ConflatedBroadcastChannel as its implementations. They served us well for a while, but they turned out to be a design dead-end. Now, since kotlinx-coroutines version 1.4 we have introduced a better solution -- shared flows. Read on for the full story. Flows are simple In the early versions of the library, we had only channels and we tried to implement various transformations of asynchronous sequences as functions that take one channel as an argument and return another channel as a result. It means that, for example, a filter operator would run in its own coroutine. Diagram of filter operator with channels The performance of such an operator was far from great, especially compared to just writing an if statement. In a hindsight, it is not surprising, because a channel is a synchronization primitive. Any channel, even an implementation that is optimized for a single producer and a single consumer, must support concurrent communicating coroutines and a data transfer between them needs synchronization, which is expensive in modern multicore systems. When you start building your application architecture on top of the asynchronous data streams, the need to have transformat