DynamoDB architecture

1. Choose the lookup key

Your game looks up a player’s best score using a unique player ID. Display names can change and are not unique.

Which partition key fits this access pattern?

playerId, a stable unique identifier.

Start with how you read the data. A score or display name cannot reliably identify one player.

The diagram now routes each lookup by playerId.

KeySchema: [{ AttributeName: "playerId", KeyType: "HASH" }]

2. Read the item you need

You already know that the player ID is p-42. The table contains millions of players.

Which operation retrieves that exact item?

GetItem with playerId = p-42.

GetItem takes the primary key. Scanning reads across the table and is unnecessary for this exact lookup.

The lookup selects p-42 rather than scanning every score.

GetItem({ TableName: "scores", Key: { playerId: { S: "p-42" } } })

3. Repair an overwrite

A second PutItem uses the same primary key and replaces that player’s record. Your intent was to create only if absent.

How do you protect the existing record?

Add a condition that the key must not exist.

The primary key identifies an item. Use a conditional write when replacing an existing item would be a mistake.

A condition turns an accidental overwrite into an explicit failed write you can handle.

ConditionExpression: "attribute_not_exists(playerId)"

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.