A SaaS API sends every catalog read to the ElastiCache primary endpoint, from instances in another Availability Zone, while replicas in the cache's own zone sit idle. Writes are rare. Which change offloads those reads?
Select an answer to reveal the explanation.
Short Explanation
You are asking the one person who can edit the book to also read it aloud for the whole room. Reads belong on the reader endpoint, which spreads connections across replicas, while writes stay on the primary endpoint. Pinning a node endpoint to the primary just keeps the crowd in the same chair.
Full Explanation
On an ElastiCache for Redis replication group with cluster mode disabled, the primary endpoint always resolves to the primary and is the right target for writes. The reader endpoint is a DNS name that spreads incoming connections across the read replicas, so catalog reads stop crossing to the primary and stop concentrating on one node. A node endpoint pinned to the primary's address is still the primary, so the idle replicas stay idle. Disabling cluster mode is not what creates read distribution. This group already has a primary endpoint and replicas, and the primary endpoint does not balance reads. Memcached can place keys across nodes, but it does not replicate and it is the wrong swap when the requirement is to keep Redis writes on a primary and spread Redis reads. Caveat: the reader endpoint is a DNS round robin across replicas, not a per-command load balancer, and replica reads can lag the primary by a short replication delay. Operational check: watch primary and replica CPU after the client change and confirm replica connections rise while primary read traffic drops.