Phone vs Cable

There are only two basic paradigms for communicating between things (threads, processes, containers, machines, hardware) in software.

The first is based on explicit requests, basically like a telephone. One computer phones up another computer, they talk, then the line is closed.

The other is broadcast based like cable TV. A source computer sends out a signal over a wire, everyone else just listens to the different channels.

Request-based communication is very specific, but also expensive. That is, you can request a piece of data, but both the server and client have to be actively involved. If there is a small number of clients this works quite well, but it usually fails to scale.

Broadcast-based communication is very general, but also relatively cheap. One server can stream out tonnes of different channels. If it’s capable, it can do it steadily.

Request-based systems degrade under a heavy load. If too many people connect, they tend to either slow down for everyone or drop connections.

Broadcast systems are independent of load. If they are set up to handle N channels, then they can consistently do that going forward. As long as the server can handle sending out M channels you can go from N to M.

If you need to ensure that the two machines actually reliably communicated something to each other then requests are far better. The client can ensure that it actually gets the data, or that it will continually retry until it is retrieved. The server knows exactly what it got and from which client.

For broadcast, the server often doesn’t even know who the clients are, how many of them are out there, or what they have received. For a client, if it misses part of the stream, and there is no historic cache of the older broadcasts, then it will not be aware of the data.

Over the decades, there have been lots of technologies that try to combine both paradigms. They might receive a broadcast, but then be able to initiate a connection as well. Or it is request based but receives a stream of something like events or updates later. While that gives the best of both worlds, it does still open up the servers to performance problems, just that they are less frequent.

There is a slight difference in error handling. For requests, the client needs to keep retrying until it is successful. For broadcasts, the client needs to be aware of its own uptime, and do extra processing in order to fill in any gaps that occurred.

Phrased as “phone vs cable” it is pretty easy to remember which basic properties are tied to which paradigms. Sometimes it is obvious which one you need, but sometimes the trade-offs are difficult. Usually, the difficulties are mixed with issues about integrity, frequency, and correctness.