003 - DynamoDB Single Table Design

ADR Metadata ACCEPTED

Date

2024-01-01

Deciders

Architecture Team

Context

The system requires high-performance reads and writes for tracking request status. We need to query by Request ID (Get Item) and also query by Client ID and Date (Query Collection). Using multiple tables in DynamoDB can lead to higher costs (provisioned throughput waste) and more complex application logic for joins (which don’t exist in DynamoDB).

Decision

We will use a Single Table Design strategy in DynamoDB.

Table Schema:

• Partition Key (PK): Generic string (e.g., REQID#<ID>, CLIENT#<ID>).
• Sort Key (SK): Generic string for entity types (e.g., METADATA, STEP#01).

Access Patterns:

1. Get Request Metadata: PK=REQID#123, SK=METADATA.
2. Get Request History: PK=REQID#123, SK begins_with(STEP#).
3. List Requests by Client: GSI1_PK=CLIENT#777, GSI1_SK=TIMESTAMP.

Consequences

✓ Positive Consequences

• Performance: Single round-trip to fetch multiple related items (if modeled correctly).
• Cost: Shared throughput across different entity types.

✗ Negative Consequences

• Flexibility: Harder to change access patterns later compared to SQL.
• Learning Curve: Requires deep understanding of DynamoDB modeling.