Day 12: DynamoDB Streams — Continued and Single-Table Design Preview

Phase 5 · Aug 23, 2026

Agenda (2–3 hours)

• Read (45 min): Alex DeBrie "The DynamoDB Book" Chapter 4 (single-table design); "Single Table Designs with Amazon DynamoDB" re:Invent talk (YouTube)
• Study (45 min): Model a blog platform (users, posts, comments, tags) in a single DynamoDB table; list all access patterns first
• Practice (45 min): Implement 5 access patterns for the blog model in Rust; verify with integration tests against a local DynamoDB (DynamoDB Local via Docker)
• Challenge (30 min): When does single-table design become a liability? Name 3 scenarios where multiple tables is the better choice

Why Single-Table Design?

DynamoDB's strengths:

• Single-digit millisecond latency
• Scales to any throughput

DynamoDB's constraint:

• One request = one API call (no joins, no cross-partition queries)

To fetch a "user profile + their recent posts + their follower count" in one API call:
→ All three entities must be in the same partition

Single-table design: pack multiple entity types into one table using a generic schema + well-designed keys.

Generic Schema

PK              SK                  Type     Data
------          ------              ----     ----
USER#alice      PROFILE             User     { name, email, joined_at }
USER#alice      POST#2026-01-15     Post     { title, body, tags }
USER#alice      POST#2026-01-20     Post     { title, body, tags }
USER#alice      FOLLOWER#bob        Follow   { followed_at }
POST#p-123      COMMENT#c-1        Comment  { text, by, at }
POST#p-123      COMMENT#c-2        Comment  { text, by, at }

PK = entity identifier, SK = entity type + identifier.
Query PK = USER#alice AND begins_with(SK, 'POST') → all of Alice's posts.

Access Patterns

Design the table around your access patterns, not your entity model:

The GSI ("global secondary index") handles cross-partition access patterns.

Hierarchical Data

Parent-child relationships in a single partition:

PK                      SK
ORG#acme                ORG                 # org profile
ORG#acme                DEPT#engineering    # department
ORG#acme                DEPT#marketing      # department
DEPT#engineering        EMP#alice           # employee
DEPT#engineering        EMP#bob             # employee

Query PK = ORG#acme → organization + all departments in one round trip.
Query PK = DEPT#engineering → all employees in engineering.

Key Takeaways

• Single-table design collocates related entities by partition key for multi-entity queries in one call
• Use PK#entity-id, SK: TYPE#sub-id as the key pattern; GSIs handle cross-partition access
• List access patterns before designing the table — the model serves the patterns
• Single-table design is complex to maintain; use it only when access latency justifies the complexity

Tomorrow: Phase 5 Week 2 Challenge — design and implement a single-table DynamoDB schema.