Strong consistency means that as soon as data is written, anyone reading it will see the latest version, no matter where they access it from. Eventual consistency means that after a write, it may take a short time for all copies of the data to update, so different users might see slightly different versions for a moment. Choosing between them is a tradeoff between having perfectly accurate data immediately and having a faster, more scalable system.
A NoSQL database like Bigtable is built for massive scale and often uses eventual consistency. When data is written to one cluster, it is replicated to others asynchronously. This can cause replication lag, meaning a user might write data and then not see their own change if they immediately read from a different cluster. This "read-your-writes" inconsistency is a known tradeoff for gaining high performance and availability.
Cloud Storage uses strong consistency for object uploads and metadata. When you upload a file or change its details, the system guarantees that the next read—from anywhere—will return that new data. This simplifies application development because programmers don’t have to write extra code to handle temporary mismatches between data copies.
Services use multi-regional replication to protect data and keep it available during an outage in one location. Cloud Storage can replicate objects across regions for high availability, and it maintains strong consistency even in this setup. Bigtable uses multi-cluster deployments for the same reason, but its eventual consistency model means the tradeoff for this availability is the potential for temporary data inconsistency across regions.
The CAP Theorem states that a distributed system can only prioritize two of three properties: Consistency (all data is the same everywhere), Availability (every request gets a response), and Partition Tolerance (the system works even if parts of it can’t communicate). In cloud databases, this often means choosing between strong consistency (C) and high availability (A) when network partitions (P) occur.
For applications where data must be perfectly accurate, like financial transactions, you choose services that prioritize strong consistency. Cloud Spanner provides this globally by using synchronous replication; it waits for all copies to update before confirming a write. Cloud SQL and AlloyDB also provide strong consistency for their primary databases, ensuring every transaction is complete before it’s visible.
When handling enormous traffic, like for user activity logs, high availability and performance are often more critical than immediate consistency. Bigtable and Cloud Storage favor availability and partition tolerance, using asynchronous replication. This allows them to scale horizontally and remain fast, accepting that reads might temporarily return stale data.
When using an eventually consistent system, you must design your application to handle stale data. Strategies include routing a user’s requests to the same cluster where they wrote data, or designing features where slight delays in updates are acceptable. This allows you to optimize for low-latency global performance while mitigating the user-facing impact of replication lag.
Cloud Spanner is unique because it delivers strong external consistency across the globe. It uses a technology called TrueTime to synchronize clocks across all its servers, ensuring transactions are processed in the exact order they occurred. This means an application can read and write from any location worldwide without worrying about data conflicts or stale reads, simplifying global application design.
Cloud SQL and AlloyDB use a primary instance that handles all writes. They can replicate data to read replicas or secondary clusters. This replication can be synchronous (waiting for confirmation) for high integrity, or asynchronous (sending data and continuing) for better performance. The asynchronous method is common for read replicas, which creates the possibility of replication lag.
Replication lag is the delay between a write on the primary database and its appearance on a read replica. Applications that use read replicas to scale must account for this. For example, showing a user their own profile update might need to read from the primary, while showing a public feed can safely read from a replica. This is the core tradeoff: read replicas increase read scalability but can temporarily reduce transactional integrity for users reading from those replicas.
The choice depends on the application's needs. Financial systems require the strong consistency of Cloud Spanner, Cloud SQL primary, or AlloyDB primary. Features like comment threads or product catalogs can often tolerate the slight delay of reading from an asynchronous replica to gain scalability and lower latency for users around the world.
A decision tree that branches based on whether an application requires strong consistency or can tolerate eventual consistency, leading to the selection of Cloud Spanner, Cloud SQL, AlloyDB, Cloud Storage, or Bigtable.
Professional Cloud Developer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts