SAA-C03 Design High-Performing Architectures Practice Question

Your application uses ElastiCache Redis as a cache for user profiles stored in DynamoDB. You must ensure that when a profile is updated, subsequent reads see the latest value quickly. Which cache strategy is generally the best fit for this requirement?

⚠ Common exam trap

Test-takers frequently confuse eventual consistency within Redis replication (which only applies to Redis-to-Redis sync) with the need to synchronize the cache with the authoritative data store (DynamoDB), leading them to pick option D, which does not address the core requirement of reflecting DynamoDB updates in the cache.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use a cache-aside approach with TTL plus explicit invalidation after writes.

A cache-aside (lazy loading) strategy with TTL and explicit invalidation ensures that after a write to DynamoDB, the stale Redis entry is removed, forcing the next read to fetch the fresh profile from DynamoDB and repopulate the cache. This combination minimizes the window of stale reads while maintaining high read performance, which is critical for user profile caches where consistency matters.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Write to DynamoDB only, and never update or invalidate the Redis cache.
Why it's wrong here
Writing only to DynamoDB while never invalidating or updating the Redis cache means every read served from Redis returns the previously cached, now-stale value. Even if a TTL is set, the stale data can live for the full TTL duration, which directly violates the requirement that updates become quickly visible. This approach sacrifices correctness for simplicity because the cache is never told that the source of truth changed, so it cannot reflect the new data until expiration. You must either invalidate the key on writes so the next read reloads from DynamoDB, or proactively update the cached value.
✓
Use a cache-aside approach with TTL plus explicit invalidation after writes.
Why this is correct
A cache-aside (lazy loading) pattern reads from cache first; if missing/expired, it fetches from the source of truth. After an update, explicitly invalidating or updating the cached entry ensures subsequent reads quickly reflect changes. TTL provides protection against missed invalidations while invalidation accelerates correctness after writes.
✗
Cache only for reads, and do not fetch from DynamoDB when a key is missing.
Why it's wrong here
If you do not fetch from DynamoDB on cache misses, you can return empty or incorrect responses. Cache-aside requires falling back to the source of truth. This option would break the functionality under cache misses.
✗
Rely on eventual consistency of Redis replication to propagate updates to all nodes.
Why it's wrong here
Relying on Redis replication to propagate updates to all nodes is fundamentally orthogonal to application-level cache correctness. Replication only copies Redis write commands from the primary to replicas; it does not know anything about changes made to DynamoDB, nor does it trigger any invalidation of keys that correspond to changed records. If the application never writes to Redis after a DynamoDB update, all nodes—primary and replicas—will continue serving the same stale cached entries. Moreover, replication lag can cause different nodes to return different values, making consistency worse, so this approach provides no benefit for reflecting source-of-truth changes.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question