On the left side, you have multiple endpoints communicating with each other using either REST APIs, SOAP or GraphQL APIs. As you can see on the left, building the systems and having them working together can be a bit of a challenge. Every single combination would have its own way to transform and pass data along the architecture. This architecture would lead to a lot of redundancy in the systems. Moreover, what happens in one of my Java services go down for ten minutes? Does my React application completely stops? Wouldn’t that make it a single point of failure for my applications?

The architecture on the right is a much cleaner to solve this issue as the entire logic of our data processing flow is centralized in the ESB.

The ESB will take care of implementing transformers (see EIP patterns) that will handle once and for all every single data transformation that our systems might need.

But, as every single piece of information is going through the ESB, doesn’t that make it a single point of failure also?

ESB are heavily coupled with messaging middlewares that, if implemented correctly, will be able to ensure that no data is lost along the way. Entreprise Service Buses are heavily coupled with asynchronous communication, meaning that counterparties don’t have to be active at the same time to be able to communicate, thus ensuring data reliability even in case of networks interruptions.

III) When to use?

Implementing resilient and robust architectural patterns is not a goal in itself, it is a way for you to ensure that data resiliency is maintained along the data flow. As a consequence, entreprise service buses are not meant to be used anytime, anywhere, in any situation.

Do I need it?

In small monolithical applications, that have a very standard workflow, entreprise service buses integration would increase the application complexity and the development time. On the other side, for large applications, that rely heavily on other applications to work, it is a perfect architectural component to use.

Is my system exposed to network failures?

If your system is communicating over the network with other applications or third parties applications, you may want to add an ESB to ensure that no messages are lost along the way. In this case, ESB are very crucial as one message lost can have tremendous impacts on the state of your processes and on the application itself.

Is my application the small part of something bigger?

This criteria applies for people working for very large companies. Often, those large companies divide the work in different services and they obviously cannot force every single developer in every single team to use specific patterns to code.

If we take the example of Google, the Google Maps team might code everything in Go, while the Google AI Team will code all its stack in Python. In this case, as frameworks and systems are inconsistent with each other, an ESB is a perfect block to add to your stack. Coupled with smart routing patterns, you can develop a workflow that will enable complex applications to work with each other without any difficulty.

So.. are you going to add an ESB to your stack tomorrow? If so, leave me a comment below.

Are you passionate about software architecture and software engineering? Make sure to check out my other publications on the subject, and to leave a clap if you liked the article!

SCHKN