Why peer to peer is a flawed architecture for most messaging needs

If you’ve spent any time architecting or implementing solutions that rely on messaging, you’re surely familiar with the concepts behind broker-based messaging. In a nutshell, message brokers centralize common networked application requirements like:

• figuring out what information is needed where
• making the application fault tolerant
• scaling as requirements grow
• securing data access
• finding and fixing faults

By performing these functions in a shared broker, you offload a lot of work from each application, and get centralized management, security, scaling and so on.

In the area of high-frequency trading, some algorithmic trading strategies live and die by their ability to get market data a few microseconds before the competition. For these scenarios every single microsecond architects can cut out of their system drives bottom line value, to the point that they’re willing to sacrifice the functions and advantages described above to do so. In response to this need, along came “peer-to-peer” messaging, which features no broker and pushes responsibility for messaging logic to publishing and subscribing applications. For latency sensitive market data customers that want to trade manageability for microseconds, and are willing to code messaging logic into their apps, peer-to-peer can be a good solution.

Outside of this arena of ultra low latency market data delivery, brokered messaging is the preferred architecture 99% of the time. This hasn’t deterred some of the peer-to-peer vendors from marketing their market-data messaging solutions for use in the middle or back office where a handful of microseconds makes no meaningful difference to the application. Especially for guaranteed messaging, peer-to-peer is fundamentally flawed as an architecture, and the trade off in features, manageability and function is not worth the claimed benefits.

With input from multiple customers who have taken a hard look at peer-to-peer vs. brokered messaging, our CTO Shawn McAllister recently wrote a white paper outlining the two architectures to highlight when each is best.