When building systems that span multiple computers, like our ERP, we enter a world of trade-offs. We learned that networks are unreliable and that guaranteeing a message was received is impossible. We also saw that trying to force traditional, single-database ACID guarantees across multiple systems with Two-Phase Commit is slow and fragile.

This leads to a fundamental rule in distributed systems, a concept so important it has a name: the CAP Theorem., an idea first proposed by researcher Eric Brewer. It says that for any distributed data store, you can only pick two of three guarantees: Consistency, Availability, and Partition Tolerance.

Let's define these terms in the context of our ERP system.

Here’s the catch: in any real-world distributed system, network failures happen. As we learned with the Two Generals' Problem, you can't wish them away. This means Partition Tolerance (P) is not optional. You must design for it.

So, if P is mandatory, the CAP Theorem really means: When a network partition happens, you must choose between Consistency (C) and Availability (A).

Let’s return to our ERP. The sales team in New York enters a huge order, which starts reducing the inventory count. At the same moment, a network switch fails, cutting off communication with the warehouse system in Chicago.

What happens now?

• Choose Consistency (CP System): The system prioritizes a single source of truth. Since the warehouse can't confirm the new inventory level, the entire ERP might become unresponsive or return an error to any user trying to view inventory. The system is 'correct', but it isn't usable. It sacrifices availability to prevent anyone from seeing potentially conflicting data.

• Choose Availability (AP System): The system prioritizes being operational. The sales team's order is accepted. Someone in the Chicago warehouse checking inventory might see the old count for a few seconds or minutes until the network is restored and the systems can sync up. The system remains usable for everyone, but at the cost of temporary eventual consistency..

For a modern, global ERP that needs to be scalable and resilient, choosing Availability is almost always the right call. A few moments of stale data is a manageable problem. An entire system that goes offline because of a network hiccup is a disaster.

This is why we need a new pattern. If we can't have the iron-clad, immediate consistency of an ACID transaction, we need a way to manage these temporary inconsistencies and ensure the system becomes correct over time. That's exactly what the Saga pattern is designed to do.

Ready to check your understanding?