A developer is designing the backend for a multiplayer game where the game session state i… — AWS Certified Developer - Associate

A developer is designing the backend for a multiplayer game where the game session state is stored in an Amazon DynamoDB table. The table structure is defined as follows:
- Partition key: ` $GameSessionId$ ` (String)
- Sort key: ` $PlayerId$ ` (String)
- Attributes: ` $Score$ ` (Number), ` $SessionStatus$ ` (String), ` $MatchDetails$ ` (Map, size $12\text{ KB}$ )

The application must support the following requirements:
1. Retrieve the top $10$ highest scores for a specific ` $GameSessionId$ ` in real-time with strong consistency.
2. Every $10\text{ seconds}$ , retrieve a list of all active sessions (where ` $SessionStatus$ ` is $\text{"ACTIVE"}$ ) to display on a public lobby dashboard. The number of active sessions is typically small (fewer than $100$ at any time), but the table contains millions of completed sessions.
3. Minimize provisioned write capacity consumption. Players update their ` $Score$ ` and ` $MatchDetails$ ` frequently (up to $100\text{ writes/sec}$ per session).

Which two configurations should the developer implement to meet these requirements with the lowest latency and cost?

Create a Local Secondary Index (LSI) with ` $GameSessionId$ ` as the partition key and ` $Score$ ` as the sort key. Configure the LSI projection to `KEYS_ONLY` to prevent the $12\text{ KB}$ ` $MatchDetails$ ` attribute from being copied, thereby minimizing write capacity consumption during score updates.Cevap
Create a Global Secondary Index (GSI) with ` $SessionStatus$ ` as the partition key and ` $GameSessionId$ ` as the sort key, configured with `KEYS_ONLY` projection. In the application, set ` $SessionStatus$ ` to $\text{"ACTIVE"}$ when starting a session, and delete the ` $SessionStatus$ ` attribute when the session completes.Cevap
C
Create a GSI with ` $SessionStatus$ ` as the partition key and project all (`ALL`) attributes. When players update their score, resolve any write throttling on the base table by scaling up the base table's provisioned write capacity units, assuming the limit is due to the overall table capacity.
D
Perform a `Scan` operation on the base table with a `FilterExpression` of ` $SessionStatus$ = 'ACTIVE'` to populate the dashboard, and use a local cache inside the application to reduce the query frequency to once every $10\text{ seconds}$ .
E
In the AWS Lambda function that updates scores, initialize the DynamoDB client by hardcoding the AWS Access Key ID and Secret Access Key of a dedicated IAM user with full DynamoDB permissions to bypass IAM role assumption latency and optimize write performance.

Cevap

Create a Local Secondary Index (LSI) with KEYS_ONLY projection, and create a Global Secondary Index (GSI) configured with KEYS_ONLY projection while using a sparse index pattern in the application logic.

To satisfy query pattern 1 with strong consistency, a Local Secondary Index (LSI) is required since Global Secondary Indexes (GSIs) do not support strongly consistent reads. By using a KEYS_ONLY projection for the LSI, we prevent the large 12 KB MatchDetails attribute from being projected. When a player's score is updated, DynamoDB only writes the modified score and keys to the LSI, consuming 1 WCU (or 2 WCUs if deleting and writing) instead of the 12 WCUs that would be consumed if the MatchDetails attribute was projected (e.g., using ALL projection). To satisfy query pattern 2, a sparse GSI is created by setting SessionStatus as the partition key and only writing 'ACTIVE' when a session is live, deleting the attribute upon completion. This keeps the GSI extremely small (under 100 items). By configuring the GSI with KEYS_ONLY projection, updates to Score and MatchDetails on the base table do not trigger GSI writes because those attributes are not projected. This prevents GSI write throttling and avoids hot partition issues on the 'ACTIVE' key.

Adım Adım Çözüm

Select the correct index for retrieving the top scores for a specific game session.

Create a Local Secondary Index (LSI) on the base table using GameSessionId as the partition key and Score as the sort key.

This allows querying within the partition to get sorted results with strong consistency.

Determine the optimal projection strategy for the LSI to minimize write capacity costs.

Set the LSI projection to KEYS_ONLY.

This avoids copying the large MatchDetails attribute to the LSI on every score write, reducing the write capacity consumption from 12 WCUs to 1 WCU per update.

Select the correct index design for retrieving active sessions.

Create a sparse Global Secondary Index (GSI) with SessionStatus as the partition key and GameSessionId as the sort key, and only populate SessionStatus with 'ACTIVE' when the session is live.

This excludes completed sessions from the GSI, creating a small index containing only active sessions, which can be queried instead of scanning the millions of base table rows.

Optimize the GSI projection to prevent write capacity bottlenecks.

Use KEYS_ONLY projection on the GSI.

Since the frequently updated attributes (Score and MatchDetails) are not projected in the GSI, player score updates do not trigger GSI writes, preventing GSI write capacity exhaustion and hot partitions on the 'ACTIVE' key.

Anahtar Kavram

DynamoDB Local and Global Secondary Index write capacity optimization, sparse indexes, and projection selection.

Tahmini Süre:3m 0s

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru