Centralized Versus Decentralized
A first decision we have to make is whether to work with a central server or not. It makes a big difference in the resulting design. The trade-offs are these:
Conceptually, a central server is simpler to understand because networks are not naturally symmetrical. With a central server we avoid all questions of discovery, bind versus connect, and so on.
Generally, a fully distributed architecture is technically more challenging but ends up with simpler protocols. That is, each node must act as server and client in the right way, which is delicate. When done right, the results are simpler than using a central server. We saw this in the Freelance pattern in Chapter 4.
A central server will become a bottleneck in high-volume use cases. If handling scale on the order of millions of messages a second is required, we should aim for decentralization right away.
A centralized architecture will scale to more nodes more easily than a decentralized one. That is, itâs easier to connect 10,000 nodes to one server than to each other.
So, for the Clone pattern weâll work with a server that publishes state updates and a set of clients that represent applications.
Get ZeroMQ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
