Google Cloud Platform Recommends Strong Consistency in Data Stores

| by Thomas Betts Follow 48 Followers on Feb 05, 2018. Estimated reading time: 1 minute |

Creating an application platform that reduces complexity and the potential for bugs starts with a foundation of strong consistency in the data layer. That is the premise outlined on the Google Cloud Platform Blog in a recent post by Mike Curtiss. According to Curtiss, "Put another way, data stores that provide transactions and consistency across the entire dataset by default lead to fewer bugs, fewer headaches and easier-to-maintain application code."

Developers who have worked in any system that has to handle concurrent data access will be familiar with the scenarios which Curtiss outlines. Transferring money between two bank accounts is a textbook example of the need for external consistency. However, solving this consistency within application logic can lead to bugs, additional complexity, and other unexpected complications. By comparison, using a data store that provides external consistency by default allows the application logic to be simplified. This leads to a more robust system, as well as increased productivity of the development team.

Cloud Spanner, Google's relational database service is built with strong consistency as a fundamental capability. Spanner's combination of horizontal scalability with strong consistency has led to a claim that it appears to violate CAP Theorem.

The blog post offers a good comparison of some of the consistency levels used by various data stores. Curtiss also tries to challenge some common assumptions, such as the performance hit of external consistency being an unreasonably high cost. However, since Spanner was developed from the ground up to provide strongly consistent reads, it avoids limitations which developers have come to accept with most data stores.

While the intent is to promote the capabilities of Spanner, the post also provides general-purpose guidance. First, always use strong reads, whenever possible. In situations where strong reads aren't feasible, then using reads with bounded staleness is a reasonable fallback, as long as the compromises are acknowledged. Strong writes are arguably more important than strong reads. If a system does not provide strong writes, then an additional burden falls on the application developers, and potentially introduces the risk of inconsistent data.

The Google Clound Platform has additional information on Cloud Spanner and external consistency.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you