Question

Difficulty: HardApplication Caching and Session State Management

A developer is building a real-time collaborative whiteboarding application on AWS. The application requires a fast, external session store to track active users' presence and canvas coordinates. The session store must support advanced data structures (such as hashes and sets), low-latency pub/sub messaging for instant updates, and automatic failover to prevent session loss. Additionally, the developer must ensure that session data is automatically removed after 1515 minutes of inactivity.

Which TWO configurations or architectural decisions should the developer implement to meet these requirements? (Select TWO.)

  1. Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled.Answer
  2. Use the Redis EXPIRE command to set a 900900-second Time to Live (TTL) on each session key.Answer
  3. C
    Store session state in AWS Secrets Manager and configure a custom Lambda function to rotate and delete session tokens every 1515 minutes.
  4. D
    Store session state in a DynamoDB table and configure a cron-scheduled Lambda function to run a Scan operation every 1515 minutes to delete stale sessions.
  5. E
    Write session data to a local variable inside a Lambda function's handler to persist the state across subsequent invocations of the same collaborative room.

Answer

The developer should deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled, and use the Redis EXPIRE command to set a 900900-second Time to Live (TTL) on each session key.
Deploying an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover provides the necessary support for hashes, sets, and pub/sub messaging along with high availability. Setting a 900900-second TTL using the Redis EXPIRE command ensures that the key is automatically evictable by Redis after 1515 minutes of inactivity without requiring any external cleanup processes.

Step-by-Step Solution

1
Analyze the requirements for data structures, messaging, and high availability.
Identify that the cache layer must support advanced structures (hashes/sets) and pub/sub capabilities, which points to Redis rather than Memcached or DynamoDB DAX.
Redis is a key-value store that supports complex data types and built-in pub/sub commands, whereas Memcached is simpler and DAX does not offer native pub/sub capabilities.
2
Address the high availability and failover requirements.
Select ElastiCache for Redis with Multi-AZ and automatic failover enabled.
This configuration guarantees replication and automatic promotion of a replica to primary in the event of a primary node failure.
3
Determine the optimal mechanism for removing inactive session data after 1515 minutes.
Use the Redis EXPIRE command on each key with a timeout value of 900900 seconds.
Redis natively manages key eviction on expiration, avoiding the need for external clean-up scripts or inefficient database scans.

Key Concept

Selecting and configuring the correct external caching and session state mechanism based on application requirements (such as data structure support, replication, and TTL cleanup).
Rate this question