Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A global gaming company is architecting a low-latency caching and state store on Google Cloud to handle millions of active sessions. The engineering team requires horizontal write scalability across multiple shards and needs to scale out read throughput across multiple zones while maintaining minimal client response times.
The team decides to deploy Memorystore for Redis Cluster (or Memorystore for Valkey) in Cluster Mode Enabled with read replicas provisioned for each shard, configuring client connections to issue the READONLY command to read directly from replica nodes.
According to distributed systems design trade-offs and the CAP theorem, what architectural trade-off must the team accept with this configuration?
Write operations will require a synchronous two-phase commit across all shard replicas, leading to increased write latency and blocking during cross-zone network partitions.
Cluster scaling requires freezing all active primary nodes and draining client connection pools, preventing any write operations during shard rebalancing.
Every read request automatically acquires a pessimistic lock on the underlying hash slot across the cluster, causing high transaction contention under heavy traffic.
Read operations directed to replica nodes may return stale data due to asynchronous replication, and acknowledged writes can be lost during an unplanned failover.
Write operations will require a synchronous two-phase commit across all shard replicas, leading to increased write latency and blocking during cross-zone network partitions.
Cluster scaling requires freezing all active primary nodes and draining client connection pools, preventing any write operations during shard rebalancing.
Every read request automatically acquires a pessimistic lock on the underlying hash slot across the cluster, causing high transaction contention under heavy traffic.
Read operations directed to replica nodes may return stale data due to asynchronous replication, and acknowledged writes can be lost during an unplanned failover.
In distributed in-memory data stores like Memorystore for Redis Cluster and Memorystore for Valkey, Cluster Mode Enabled partitions data across multiple primary shards (from 1 to 250 shards) to achieve horizontal scalability. To maximize write performance and provide sub-millisecond response times, replication from primary nodes to read replicas is performed asynchronously.
StudyCerts
StudyCertsREADONLY command, reads do not wait for synchronous replication acknowledgments. If a primary node accepts a write, there is a propagation delay before that write reaches every replica, meaning replica reads may serve stale data.For ephemeral session states, leaderboards, and caching layers, sacrificing immediate strict consistency in exchange for massive horizontal read/write scale and minimal network latency provides the best performance balance.