Prepare and test your skills
Prepare and test your skills
Applying Consistency, Availability, and Partition Tolerance (CAP) principles means selecting a storage service based on which guarantee matters most when the network separates locations. Consistency means every reader sees the latest write immediately after an update. Availability means every replica stays readable even before replication finishes, while partition tolerance means the system keeps working across zones and regions despite delays or failures. Because a distributed system cannot provide all three guarantees at once during a partition, service selection is a tradeoff between seeing fresh data and staying fast and reachable.
The CAP tradeoff is visible in how replicas handle a write that flows from an originating node to its replicas. With eventual consistency (opens in a new tab), data flows from originating Node A to replica Nodes B and C without blocking reads, so replicas stay available but a reader of B or C may briefly see stale data. With strong consistency, also called immediate consistency, the system locks data during the update and replication process, so replicas stay consistent with Node A but are not accessible until the update finishes. The Internet Domain Name System (DNS) shows the eventual side succeeding at scale, because cached values replicate across many directories and servers stay highly available for more than a hundred million lookups even though changes take time to reach every client.
Strong consistency costs scalability and performance because locking prevents other processes from updating the same data during replication. Eventual consistency avoids that lock, which improves throughput and keeps reads responsive under load and across distance. Choose strong consistency when every observer must agree immediately after a write, and choose eventual consistency when brief staleness is acceptable in exchange for higher availability and lower latency.
Use-case size and user context determine whether stale data harms the experience and therefore which consistency behavior to select. Large result sets with broad context tolerate missing or extra items, while small result sets with narrow context make every missing or extra item obvious to the user. Non-relational databases let an application mix both models instead of forcing one choice for all data.
Eventual consistency fits when approximate or delayed views are acceptable:
Strong consistency fits when correctness depends on seeing the latest write:
When the context makes users aware of which entities should be included, select a strongly consistent read path even if it costs extra latency or throughput.
Bigtable (opens in a new tab) replication improves read scale and geographic latency but does not increase write throughput. A write received by one cluster must be replicated to every other cluster in the instance, and each cluster spends CPU resources pulling changes from the other clusters. Replication for Bigtable with multi-cluster routing is eventually consistent, and replication latency generally grows with distance, so clusters in different regions typically lag more than clusters in the same region.
The scaling tradeoff is concrete when total nodes are held equal. A single-cluster instance with 3 nodes that grows to 6 nodes in one zone doubles write throughput because all 6 nodes serve the same write path. A replicated instance with two 3-node clusters in two zones writes each piece of data twice, once on receipt and once on replication, so write throughput does not increase and may decrease while availability spans two zones. For that reason, a cluster in a multi-cluster instance often needs more nodes than a single-cluster instance with similar application traffic, because each cluster handles both application load and replication work.
Routing controls whether an application optimizes for lowest latency or for workload isolation. An app profile with multi-cluster routing automatically routes requests from the application to the closest cluster, then replicates writes to the other clusters, which minimizes distance-related latency. An app profile with single-cluster routing pins traffic to one cluster, which supports needs such as separating workloads or getting read-after-write semantics on that cluster but does not reduce latency the same way. Select multi-cluster routing for low-latency global reads and select single-cluster routing when isolation or immediate re-reads on one cluster matter more.
Exam tip: Adding a second Bigtable cluster improves availability and read locality, but it does not double write throughput the way adding the same nodes to a single cluster does.
Global deployment patterns decide where the frontend and backend live and how much data must be replicated to answer requests locally. A user request travels from the last-mile network to the closest Google edge point of presence (POP), then across the Google network to the Compute Engine region, then through application processing. Region selection only changes the POP-to-region and application portions, so optimizing regions helps little when last-mile latency dominates, such as on 3G cellular networks with 100-500 ms of access delay compared with 1-10 ms on modern wired networks.
| Pattern | Where frontend and backend run | Latency and consistency tradeoff |
|---|---|---|
| Single region | Frontend and backend run in one Compute Engine region | Lowest complexity; use Cloud CDN and global load balancing to reduce edge latency without syncing data across regions |
| Distributed frontend, single backend | Frontends run in multiple regions and backend runs in one region | Lower frontend latency with no cross-region data sync; works when requests need few or no round trips to the central backend, such as with intelligent frontend caching or asynchronous writes |
| Distributed frontend and backend | Frontends and backends run in multiple regions with fully replicated data | Lowest data-access latency because each region answers locally; highest complexity because all data must be stored and kept accessible in every region |
Spanner reduces the complexity of the fully distributed pattern by providing globally consistent managed replication. A three-continent multi-regional Spanner option keeps read-write replicas in the United States with read replicas in Europe and Asia, giving low-latency read access to compute in the United States, Europe, or Asia. A United States-only multi-regional option exists when the service targets the United States and needs replication within the country. Choose Spanner when global reads must remain strongly consistent without building custom cross-region replication.
Application design can hide replication lag while keeping global performance low. Placing Bigtable data geographically closer to users shortens read distance, and multi-cluster routing sends each request to the nearest healthy cluster first. A distributed frontend with caching answers many reads without a full round trip to the central backend, and handling data writes asynchronously lets the frontend respond before distant replication completes. When a fresh re-read is required, directing that operation through a single-cluster path restores read-after-write behavior for that narrow operation.
The same application must also degrade gracefully (opens in a new tab) when load spikes threaten availability. Replicas should throttle incoming requests (opens in a new tab) independently so excess traffic shifting between zones does not cause cascading failures, and tools such as Apigee can enforce API rate policies during high-traffic periods. Dropping excess requests at the frontend layer protects backend components and preserves partial availability, while building retry and partial-error handling lets the application serve as much traffic as possible. Regular overload testing plus monitoring for traffic spikes validates that throttling and early drops work before a real surge arrives.
Contrast in replication behavior is the tradeoff between always-available reads that may be stale and locked, immediate reads that cost scalability. Bigtable (opens in a new tab) multi-cluster deployments choose the first model when multi-cluster routing is used, offering eventual consistency across clusters to gain read throughput and geographic availability. Strong consistency chooses the second model, where all observers see an update immediately after it commits, but data must be locked during update or replication.
Eventual consistency (opens in a new tab) is a guarantee that if no new updates are made to an entity, all reads of that entity will eventually return the last updated value. The Internet Domain Name System (DNS) shows how this works: values are cached and replicated across many servers, so lookups stay highly available and scalable for over a hundred million devices even though some servers briefly return older values. In this model replicas stay available for reads, but a replica such as Node B or Node C may be inconsistent with the latest write on originating Node A at a particular moment.
Strong consistency, also called immediate consistency, means data viewed immediately after an update is consistent for all observers of the entity. Traditional relational databases use this model, but they compromise scalability and performance because data has to be locked during the update or replication process so no other process updates the same data. In general, workloads with very many entities where missing one result does not hurt experience, such as showing who is online or counting likes on a post, fit eventual consistency. Workloads with few entities in a narrow context where correctness is visible, such as whether billing finished or how many game points were earned, require strong consistency.
Bigtable replication copies each write from the cluster that first receives it to every other cluster in the same instance. When an instance uses multi-cluster routing, that replication is eventually consistent, so a read on a different cluster may return older data until replication completes. As a general rule, replication takes longer across greater distance, so clusters in different regions typically have higher replication latency than clusters in the same region.
Each cluster also spends CPU resources to pull changes from the other clusters, in addition to handling application load. For that reason, a cluster in a multi-cluster instance often needs more nodes than a cluster in a single-cluster instance with similar traffic. Greater distance improves geographic availability but increases the window where replicas disagree.
Routing in Bigtable is controlled by an app profile, and the app profile determines whether an application gets read-after-write consistency or lowest-latency routing. An app profile with single-cluster routing sends all requests to one cluster, which can provide read-after-write semantics on that single cluster and is useful for separating workloads. An app profile with multi-cluster routing automatically routes each request to the closest available cluster from the perspective of the application, then Bigtable replicates writes from that cluster to the other clusters in the instance.
| Routing option | Where requests go | Consistency and latency effect |
|---|---|---|
| Single-cluster routing | All requests go to one configured cluster | Reads on that cluster can see their own writes, but requests do not get closest-cluster latency reduction |
| Multi-cluster routing | Each request goes to the closest available cluster, writes replicate to other clusters | Requests get the lowest possible latency from shortest distance, but reads are eventually consistent across clusters |
Exam tip: Choose single-cluster routing when you need read-after-write semantics on one cluster; choose multi-cluster routing when you want the closest cluster to minimize latency and can tolerate eventual consistency.
Replication in Bigtable improves read throughput and can reduce read latency by placing data geographically closer to application users, especially with multi-cluster routing. Replication does not increase write throughput because every piece of data is written twice: once when first received and again when replicated to the other cluster. Write throughput might actually go down because each cluster does additional replication work.
The node example makes the tradeoff concrete. A single-cluster instance with 3 nodes that adds 3 nodes to the same cluster, for 6 nodes total, doubles write throughput but keeps data in only one zone. A replicated instance that instead adds a second 3-node cluster, also 6 nodes total, does not increase write throughput and may handle only half the writes of the 6-node single cluster, but the data becomes available in two different zones.
Failover in Bigtable (opens in a new tab) is the rerouting of traffic from an unresponsive cluster to another cluster in the same instance, and Bigtable reverts to eventual consistency after a failover. If writes have not yet replicated to the failover cluster, some reads will return stale data until replication completes. Bigtable uses an internal last write wins algorithm to resolve data conflicts that occur when failover happens before replication has finished.
The failover path depends on routing. Manual failovers apply to single-cluster routing, where you must decide when to switch clusters. Signals that may indicate a manual failover would help include:
Automatic failovers apply to multi-cluster routing, where Bigtable retries on the next closest cluster when the nearest cluster is slow or returns a transient error. If a request has a deadline, Bigtable reroutes as the deadline approaches, so a shorter deadline triggers earlier failover and a longer deadline allows more time. For high availability, locate client servers or VMs in or near more than one Google Cloud region, because data enters the Google network through the region closest to the application and failover completes faster over shorter distances.
Consistency models in relational databases define what an application sees when data is copied from a primary node to replicas. Cloud Spanner (opens in a new tab) provides global strong consistency for transactions across regions, while Cloud SQL and AlloyDB (opens in a new tab) scale reads by serving them from secondary clusters and read replica instances that copy data from the primary. The choice controls replication lag, transactional integrity, and read scalability.
Strong consistency (opens in a new tab), also called immediate consistency, means data viewed immediately after an update is consistent for all observers of the data. To provide this guarantee, data has to be locked during the update or replication process so no other process updates the same data, and replicas are not accessible until the update finishes. Eventual consistency means that, provided no new updates are made, all reads will eventually return the last updated value, but replicas stay available for reads and some replicas may be inconsistent with the latest write at a particular moment.
The two models trade availability and speed against freshness:
| Model | Replica behavior during replication | Data seen after a write |
|---|---|---|
| Strong consistency | Replicas hold values consistent with the originating node but are not accessible until the update finishes | Same latest value for all observers immediately after the update |
| Eventual consistency | Replicas stay available to read while changes replicate | Some reads may be stale, then converge to the last value if writes stop |
Strong consistency fits narrow contexts where missing an update breaks correctness, such as whether a user finished billing or how many points a player earned in a battle. Eventual consistency fits large-scale views where a missing or extra item does not change the experience, such as who is online or how many users liked a post.
Cloud Spanner is a distributed relational database that provides strong transactional consistency at global scale without forcing every transaction to pay the same coordination cost. Spanner assigns timestamps from TrueTime to transactions and applies data at different timestamps separately in timestamp order. For blind writes that write data without first reading it in the same transaction, Spanner can let multiple single-split transactions writing the same data proceed in parallel because the TrueTime timestamps are guaranteed to be different, which avoids race conditions and data corruption.
Spanner follows the principle that an application does not pay for mechanisms it does not use. A transaction that spans splits uses two-phase commit (2PC) for coordination, while a transaction to a single split bypasses 2PC and uses a simpler, faster protocol. A strong read of the latest data may spend extra latency verifying that a replica is up to date enough to serve it, while a read that can accept stale data does not pay that verification latency. Spanner stores data with range sharding, so applications that do range scans get high performance, while applications that do not need range scans can put a hash value in the primary key to spread writes and avoid row-range hotspots.
Exam tip: In Spanner, a single-split transaction bypasses 2PC, and a stale read avoids the replica-freshness check that a strong read pays for.
Cloud SQL and AlloyDB use a primary and secondary topology where the primary database cluster accepts writes and secondary database clusters and instances function as copies of the primary resources. AlloyDB cross-data-center replication creates those secondary clusters in different data centers so the resources remain available if the primary data center has an outage. Traffic flows from the primary to each secondary copy, so the secondary depends on the primary for new writes.
Replicas that copy asynchronously behave like eventual consistency because replication takes time and a read replica can lag behind the primary. An application that writes to the primary and then immediately reads from a replica may see stale data, missing rows, or older values until replication catches up. Synchronous replication behaves more like strong consistency because the write waits for the replica, which protects transactional integrity but adds latency and reduces throughput under load.
Designing for replication lag means routing each operation to the copy that meets its correctness needs. Send money movement, inventory decrement, billing completion, and other transactions that must see the latest committed state to the primary or use a strong read. Send dashboards, product listings, feeds, and other high-volume reads that tolerate brief staleness to read replicas and secondary clusters to gain read scalability.
The core tradeoff is transactional integrity against read scalability and performance. Locking and waiting for replicas keeps every observer consistent but limits throughput because only one transaction at a time can make progress on the same locked data. Letting replicas serve reads while replication is still in flight keeps the system highly available and scalable but requires the application to handle stale reads, retries, and user experience cases where the latest write is not yet visible everywhere.
Strong consistency locks data during the update and replication process so replicas are not accessible until the update finishes and all observers see the same latest value immediately after the update. Eventual consistency keeps replicas available for reads while changes replicate, so some reads may briefly be stale but all reads will eventually return the last updated value if no new updates are made.
Use Bigtable multi-cluster routing when you want each request to go to the closest available cluster for the lowest possible latency and you can tolerate eventual consistency across clusters. Use Bigtable single-cluster routing when you need read-after-write semantics on one configured cluster or need to separate workloads, accepting that requests do not get closest-cluster latency reduction.
No, adding a second Bigtable cluster does not increase write throughput because every piece of data is written twice, once when first received and again when replicated to the other cluster, while each cluster spends CPU resources pulling changes from the other clusters. A single-cluster instance with 6 nodes doubles write throughput compared to 3 nodes because all nodes serve the same write path, while a replicated instance with two 3-node clusters may handle only half the writes of the 6-node single cluster but gains availability in two zones plus improved read throughput and geographic availability.
Last updated