PACELC Theorem — No such ring to rule them all
Among all powerful and magical races on Middle-earth, it is still surprising when Gandalf the Grey picked a hobbit to join the mission to reclaim a mountain full of gold and wealth from a monstrous fire-breathing dragon. What started as suicide mission ends in glory with significant role from the halfling creature. New smell, light foot and big luck bring a big trade off for mightiness and combat skills.
In the realm of corporations, where wizardry doesn’t really work, the quest of choosing the most sufficient platform to support business involves a lot of making trade-offs. Barrage of vendors offering, also the rise of corporation-backed open source solution only brings more shenanigans on the table. Depends on the maturity, corporations may introduce the role of architect team to design solutions fit into current enterprise-wide technology stack. While we can’t have straight analogy between architect team and Gandalf in the aforementioned scene, both have the strategic role to make sure required capabilities are intact in pursuit of successful quest, even the hardest ones.
Introducing the well-known theorem
It was actually started as a conjecture when Eric Brewer first presented a principle of making trade-off at 2000 only to see it became theorem 2 years later. He introduced three properties to be considered when designing a distributed system:
(C) Consistency: consistent system maintains only one state of data
(A) Availability: system always gives response for every request, please note that exception is not a response
(P) Partition tolerance: in the event of partition (time, location, network, etc.), system will continue to operate gracefully
This theorem declares that only when one property is allowed to be compromised, a system can maximize the other two (this IBM article describes good examples for each case). Back to our enterprise scene, it is very common to have multiple data centers to serve business. In this case, network partition (P) is introduced in the circumstances. In regard of the rule, either inconsistent data is desired (compromising Consistency) or allowing system to be less available (bargaining for Availability). Both are no fun for business and customer. Imagine seeing different balance when checking your bank account in your mobile app vs ATM, or paying for two data centers when you can only serve business with one.
Wisdom came in the following decade, when distributed databases broke in to industry. It desires for Partition, hence the name, and some are designed to achieve high Availability. Therefore, bargaining for Consistency suddenly became an option. In 2012, Prof. Abadi formalized a theorem to make CAP theorem more reasonable. Simply put, in a distributed system, when network partitioned (P) occurred, system has to choose between Availability (A) and Consistency (C), but else (E) in normal condition, system has to choose between Latency (L) and Consistency (C)— known as PACELC theorem. The Else (E) factor also supported by CAP theorem’s creator himself in an article in the same year (one of them) addressing about how picking 2 of 3 properties is misleading and causing confusion. Also note that extra property was introduced here, Latency (L) indicates the system requires an amount of time to make data consistent in all nodes.
Now back to our enterprise setting. The narrative above should be brief enough (one can always go for more explanation by exploring this article’s reference list) to give a hint on how architect team plan to design or implement a solution. They start from two angles. How a solution can fit into business when everything is in desirable condition, and what trade-offs should be contained when facing failures.
Put example a mobile banking app for transactional purpose, business needs it to serve as many customers as possible (high TPS). In this case, architect can purpose the service to be hosted in all data centers, and assign them to serve customers (also known as active-active deployment). While the nature of financial transaction is to desire for consistency, transactional database can be configured as one primarily active database to record all the transactions served by services in multiple data centers. Each data center can mirror the database via cross-site replication for disaster recovery purpose. This scenario promotes EC (Else-Consistency) condition in PACELC theorem where system goes for data consistency in normal condition, and attempts to maintain Consistency (PC) when things went south. Hence, there will be service downtime to contain the process of mirrored database being active. But this scene (PCEC) won’t be the de facto for all services in mobile banking app, some non-financial services (e.g. promotion) can be hosted in all data centers using caching to support persistence on each data center. Without the need to do cross-site data replication at once. That way, customers can happily log in and browse for promotions (EL), even when partition happened, browsing for less-fresh campaigns (PA) is still adequate. This scenario (PAEL) introduces eventual consistency, in which system allows data in all nodes to be inconsistent but gradually being consistent over time (as opposed to strong/strict consistency which demands data to be consistent all the time). Dissecting business demands became the key here as architect team plays the role to design a solution. Please note that the term solution here doesn’t have to be a technology or a platform, complication starts when solution consists of orchestrating existing technologies with the new ones.
Conclusion
We’ve covered briefly the origin of PACELC theorem with design examples inspired from real implementation. Understanding PACELC acts more like fundamental, rather than having a cheat sheet of making certain trade-off. Good understanding to business requirement, indeed, will be the primary driver of which scenarios will fit the most. Working back-and-forth to make sure solution will fit business in desired condition, also to make sure business will buy in such trade-offs in unfavorable situation.
Plot-twist
The fact that PACELC theorem has been around, some platforms are now carefully designed as configurable to fit more than one PACELC mode. Put simply, in our Middle-earth analogy, a special-breed race mighty enough to hurdle into a battle, also can be a reliable ally to negotiate with the kings
