Question

Difficulty: HardApplication Caching and Session State Management

A developer is designing a high-traffic, stateful web application that will be hosted on Amazon ECS. The application requires an external session store to maintain user session states across multiple container instances. The session store must meet the following requirements:

1. Provide sub-millisecond latency for both read and write operations.
2. Automatically delete session records that have been inactive for more than 2424 hours.
3. Ensure high availability and data persistence, even in the event of an Availability Zone (AZ) failure.

Which caching solution should the developer implement to meet these requirements?

  1. A
    Amazon DynamoDB with DynamoDB Accelerator (DAX) enabled, using DynamoDB Time to Live (TTL) to delete expired sessions.
  2. Amazon ElastiCache for Redis configured with a replication group across multiple Availability Zones, using Redis key expiration (TTL) to manage the session lifecycle.Answer
  3. C
    An AWS Lambda-based caching layer that stores session state in the function's local execution context, using a background thread to clean up inactive sessions.
  4. D
    AWS Systems Manager Parameter Store with standard parameters, using a scheduled task to rotate and delete session values after 2424 hours.

Answer

Amazon ElastiCache for Redis configured with a replication group across multiple Availability Zones, using Redis key expiration (TTL) to manage the session lifecycle.
The correct answer provides sub-millisecond latencies for both read and write operations, which is a native capability of Amazon ElastiCache for Redis. Utilizing a replication group across multiple Availability Zones ensures data replication and automatic failover to survive AZ failures. Redis key expiration (TTL) handles active key purges immediately upon expiration, fitting the 2424-hour cleanup constraint.

Step-by-Step Solution

1
Analyze the performance constraints.
The requirement for sub-millisecond latency for both reads and writes rules out solutions that do not cache writes (like DynamoDB with DAX) or services with slow transactional write speeds (like Systems Manager Parameter Store).
This establishes that the solution must use an in-memory caching system designed for rapid read/write workloads.
2
Evaluate the session lifecycle cleanup constraint.
Sessions must be deleted after 2424 hours of inactivity. DynamoDB's TTL feature does not guarantee deletion within 2424 hours (it can take up to 4848 hours), whereas Redis key expiration processes expirations in real time.
This rules out DynamoDB as a strict TTL compliance mechanism for this timeframe.
3
Evaluate the high availability and durability constraint.
An external caching tier like ElastiCache for Redis configured with replication across multiple Availability Zones provides automatic failover, keeping session data persisted and available.
This ensures the stateless application tier on ECS can survive node and AZ outages without session data loss.

Key Concept

Application Caching and Session State Management
Rate this question