The Curious Case of Consistency – Part 2

Arggghh.. I broke my promise!! I should have finished this post earlier.. :(. huffff.. ¬†I was busy with school assignments and activities with Indonesian societies in Stockholm hehe.. maybe I should write on it as well humm… okay, now back to business ūüôā

In the previous post, I wrote about several consistency types from Doug Terry‘s breakfast talk in my school. Now, it’s time to see their application in simple baseball game.

Simple Baseball Game

The baseball game itself will consist of several “entities” that are “interested” in the latest score of the game. The “entities” are represented as pseudocode, and the term “interested” can be interpreted as read or write depending on entity type. We will discuss what kind of consistency that is needed for each entity below

Continue reading The Curious Case of Consistency – Part 2

The Curious Case of Consistency – Part 1

Last week I attended interesting breakfast talk by Doug Terry, principal researcher from Microsoft Research Silicon Valley and I think it is pretty cool talk B-). The talk itself is about other consistency types which lie between Strong and Eventual Consistency, and how the additional consistency types are (practically) used through simple pseudo-code of baseball game. And this is the first of two planned posts for this topic.

Let’s start with two most basic consistency model (which we usually learn in our first Distributed System course/module in University):¬†Strong Consistency¬†and Eventual Consistency.

In Strong Consistency, every node in distributed system will always see the same and latest view after a specific node update the data. This consistency type sacrifices performance and availability in order to ensure consistent view across the node in the distributed system since it is expensive in term of network and computing resources needed to maintain the consistency. Example of system that uses Strong Consistency is Windows Azure.  Strong Consistency is desirable within a data center however performance and availability concerns start raising in geo-replication service that spans in multiple-data center.

I use strong consistency!

Continue reading The Curious Case of Consistency – Part 1

Consistency Tradeoff in Modern Distributed DB

Last week I had presentation about the relevancy of CAP theorem in modern distributed system design. This presentation is based on an article titled “Consistency Tradeoffs in Modern Distributed Database System Design” by Daniel J. Abadi from Yale University.

CAP theorem is widely used in Distributed Database System(DDBS) design. In a nutshell, it says that in designing modern DDBS, we only can choose two properties out of three properties that are crucial for DDBS. The aforementioned properties are Consistency (C), Availability (A) and Partition Tolerance (P).  And this diagram below summarize the available combination of CAP:

CAP Diagram
CAP Diagram

Now, the question here are, is there something wrong with CAP theorem? Is it still relevant with modern DDBS design? Continue reading Consistency Tradeoff in Modern Distributed DB