The Master Slave Dogma in Integrations

An argument for using event driven architectures, creating a self-healing system that supports multiple endpoints

Recently I read an eBook Integration guide titled the Ultimate Guide to Netsuite Integrations that stated “Do not allow changes from both systems.” While this is cute advice, we should also consider what happens when we have 5 systems which is not uncommon.

So back to their recommendation … let me get this right, a customer calls in and talks to support, and the customer says I would like to change my phone number. Oh’ wait, we have to create a ticket for that. I cannot change your phone number in this system, since we can only change the phone number in the other system and this could take up to 24 hours.

Here I’d like to challenge this approach and propose that any user on any system in the network should be able to update the records right there and that change should persist throughout the platform.

Event-Driven Architectures: A Modern Alternative to Master-Slave Integration

The way business systems communicate is not only paramount to overall efficiency and effectiveness, it’s a massive opportunity when done correctly. Traditionally, master-slave architectures have dominated the integration landscape. However, this centralized method of control often misrepresents the inherent distributed nature of business operations, can limit flexibility and growth, and frustrate the heck out of your users. Here we propose a more flexible and resilient approach: an event-driven architecture using topics.

1. Mirroring Real-Life Workflows The master-slave integration system limits updates to a singular location. In essence, it forces all other systems to wait in line for updates. This doesn't reflect the way teams or operations work in businesses. In contrast, with event-driven architectures, actions can be initiated from multiple touchpoints, mirroring the distributed, collaborative nature of real-world business tasks.

2. Scalability and Flexibility When you have 10 (or even more) systems that need to share information, a centralized approach becomes a bottleneck. Event-driven systems, using topics, allow you to scale out horizontally, seamlessly adding more systems into the network without disrupting the flow.

3. Resilience and Self-healing Event systems distributed nature provides inherent fault tolerance. In the face of network partitions, node failures, or other unforeseen issues, these systems can continue to process and deliver messages. The systems can heal themselves, as replicas ensure that no single point of failure exists. This contrasts sharply with master-slave systems, where the failure of the master can cripple the entire setup.

Furthermore, if a single client goes offline, it can self heal checking to see what has changed since the last time it checked in on the topic.

4. Decoupling Systems One of the most significant advantages of adopting an event-driven architecture is the ability to decouple systems. Each system, or service, interacts only with the events of interest. This loose coupling makes it easier to modify, replace, or upgrade individual systems without affecting the others.

5. Ensuring Data Consistency Once an event is published, subscribers to that event can react in near real-time. This means that all integrated systems can be updated almost simultaneously, ensuring consistency across the board.

Conclusion Event-driven architectures using topics offer a more resilient, scalable, and real-world mirroring solution than traditional master-slave integrations. By making the shift, businesses can foster a more agile and dynamic environment that can easily adapt to growing needs and unforeseen challenges.