Examkin

Question

Difficulty: Very hardApplication Caching and Session State Management

An online multiplayer gaming application uses AWS Lambda behind an Amazon API Gateway to process game lobby updates. The application stores game session states in an Amazon DynamoDB table. During peak hours, a small number of extremely popular game lobbies experience rapid, successive read and write operations (multiple updates per second), resulting in frequent 'ProvisionedThroughputExceededException' errors. How should the developer modify the architecture to resolve these throttling errors most effectively?

  1. Migrate the session state storage to an Amazon ElastiCache for Redis cluster, configuring the application to read and write session updates directly to the in-memory cache.Answer
  2. B
    Deploy an Amazon DynamoDB Accelerator (DAX) cluster in front of the DynamoDB table to cache session data, leveraging the write-through capability of DAX to automatically offload both read and write traffic.
  3. C
    Increase the provisioned write capacity units (WCUs) on the DynamoDB table and enable DynamoDB Auto Scaling to dynamically adjust the capacity during peak hours.
  4. D
    Cache the active session states in the local memory or the /tmp directory of the AWS Lambda execution context to reuse them across subsequent invocations.

Answer

Migrate the session state storage to an Amazon ElastiCache for Redis cluster, configuring the application to read and write session updates directly to the in-memory cache.
Migrating the session state storage to Amazon ElastiCache for Redis is the correct solution because it is designed to handle high-throughput, low-latency in-memory reads and writes. This removes the write-intensive session updates from the relational or DynamoDB database completely, resolving the hot partition bottleneck.

Step-by-Step Solution

1
Analyze the workload characteristics and failure points.
The workload requires high-rate read and write operations (multiple updates per second) concentrated on a small subset of popular keys, resulting in DynamoDB hot partition write throttling.
Identifying that the issue involves both reads and writes on hot partition keys is crucial to selecting the correct caching layer.
2
Evaluate DynamoDB Accelerator (DAX) capability for write-heavy workloads.
DAX is write-through, meaning writes go to the cache and the database synchronously. DAX does not absorb or reduce the write load on DynamoDB.
This rules out DAX as a solution for write throttling on hot keys.
3
Evaluate DynamoDB scaling capabilities.
Scaling up WCUs or enabling auto-scaling cannot bypass the throughput limits of a single partition (1000 WCUs) when a single hot key receives concentrated traffic.
This rules out table-level scaling adjustments.
4
Select the correct caching and state management service.
Amazon ElastiCache for Redis supports high-throughput in-memory reads and writes, bypassing the database write bottleneck for active session state.
Using ElastiCache for Redis is the industry standard for fast-moving session data with high write concurrency.

Key Concept

Caching strategies and session state management for write-heavy hot-key workloads using ElastiCache vs DAX vs DynamoDB.
Rate this question

Topics

Application Caching and Session State Management

More questions from this topic