A gaming company has implemented a leaderboard in AWS using a Sorted Set data structure within Amazon ElastiCache for Redis. The ElastiCache cluster has been deployed with cluster mode disabled and…

Question

Options

• AEnable cluster mode on the existing ElastiCache cluster and configure separate shards for the
• BIncrease the size of the ElastiCache cluster nodes to a larger instance size.
• CCreate an additional ElastiCache cluster and load-balance traffic between the two clusters.
• DUse the EXPIRE command and set a higher time to live (TTL) after each call to increment a given

• A
  4% (1)
• B
  75% (18)
• C
  4% (1)
• D
  17% (4)

Explanation

Scaling ElastiCache for Write-Heavy Workloads

Why B is Correct: When cluster mode is disabled, the only way to scale for increased write capacity is vertical scaling - increasing the node instance size (scaling up). Since all writes must go to the single primary node in a disabled-cluster-mode setup, adding replicas only helps reads, not writes. Upgrading to a larger instance type gives the primary node more CPU, memory, and network throughput to handle the anticipated write surge.

Why the Distractors Are Wrong:

• A is tempting but incorrect because you cannot enable cluster mode on an existing cluster - you must create a new cluster with cluster mode enabled from the start; migration would be required.
• C is operationally complex and not natively supported for Redis Sorted Sets, as data would need to be consistently partitioned between clusters - Redis doesn't offer built-in cross-cluster load balancing.
• D is completely unrelated to scaling write capacity; setting TTL values manages data expiration, not throughput performance.

Memory Tip: Think of it this way - "Disabled cluster mode = scale UP (vertical), Enabled cluster mode = scale OUT (horizontal with shards)." If you're stuck with cluster mode disabled, your only write-scaling lever is the node size itself.

No community discussion yet for this question.