What do you want and when do you want it?

A Adhikari
4 min readApr 1, 2022

I have recently read Replicated Data Consistency Explained Through Baseball by Doug Terry a few times over. I thought it’d be nice to ponder over it and write down my thoughts. Even if I’m the only one to ever read them.

For years I have thought about data consistency in terms of absolutes. Strong consistency: good, eventual consistency: meh. Only a Sith deals in absolutes. My non-existent grasp of baseball aside, the paper was an absolute eye opener. I know a home run is good and it’s bad when you strike out.

Anyhoo, Doug starts by mentioning six different consistency guarantees. I am copying a screenshot of them here.

These all seem straightforward, right? In most cases, most of us want our data to be strongly consistent. Why would anyone want to live any other way? But when you read further, you learn about the different actors on a piece of data.

Mind you, the more one inches closer to the truth, higher is the cost it extracts. Let’s look at the tradeoff you make to the infamous CAP triangle with all of these guarantees:

Now that we know what different guarantees are, and what CAPability(pun intended) they provide, let’s talk about a few of these actors(I have taken some liberty with these actors to simplify the point):

  • Umpires:

What kind of consistency guarantee does an umpire need? They need to know everything that has happened till now in the specific order it happened before they can decide how the game should proceed. If a striker strikes out 2 times, the ump needs to know of it before the third strike to adjudge them out. Or in limited overs cricket, you’d need to know if the previous ball was a no ball, and the current one is a free hit and the batter is not out even if the stumps were dislodged. They will need to know of timing restrictions violated by a team to say they can only bowl a spinner henceforth. That’s when it seems you will need strong consistency. Can you make do with eventual consistency? Probably in a backyard game, if you are willing to live dangerously, but not in an officiated game. The umpire has to be up to date with every thing that has happened on the field of play, exactly and immediately.

  • Fans:

Next, let’s talk about the fans, the true connoisseurs of the game. I am not sure that the fans wouldn’t love a scoreboard that always shows their teams ahead. But like us, they live in the real world. And I am okay to know the score a few seconds later. As long as it doesn’t bounce back and forth between an old and a new score. So that rules out eventual consistency. Strong consistency could do but is also an overkill. I think in this case any out of Consistent Prefix, Bounded Staleness, or Monotonic reads should work. We can hold our horses.

  • Scorekeeper:

A scorekeeper is the one keeping official records based on the decisions made my the umpires on field. Again, like others, strong consistency would work. But can we choose a different consistency guarantee which would be cheaper to implement? Eventual consistency is out of the question. We obviously don’t want results which may be all sorts of inaccurate. Bounded staleness, consistent prefix, monotonic reads also wouldn’t work because they might fetch stale information(that was correct at one point of time) which are no good for keeping the score up to date. Read my writes however would work, under the assumption of course that we have 1 scorekeeper in a game.

  • Stats providers:

There are an umpteen number of stat providers that provide us with the fanciest of stats, some that we would never have even thought we needed. Collating information from eons ago, an average of a standard deviation of a player’s score in games where the away team only wears black is a good stat to have. But I would be okay if it did not include the last pitch or the last over. With exploding data points, a degree of inaccuracy in stats should be forgivable. In this case even eventual consistency would be manageable.

Now the question to ask every time is: what do you want, when do you want it, and how accurately do you want it?

I hope I made some sense. There’s always Doug’s paper to learn more about it.

--

--

A Adhikari

A programmer by passion and a writer at heart. Well, sort of!