← Database Systems Hub
Database Systems · Guide

DynamoDB

Single-table design, GSIs, on-demand vs provisioned.

— min read Database Systems

Theory

DynamoDB: Single-table design, GSIs, on-demand vs provisioned.

Amazon DynamoDB is a fully managed, serverless NoSQL database offering single-digit millisecond latency at any scale. Unlike Cassandra (you manage the cluster), DynamoDB has no servers to provision, patch, or scale — AWS handles everything. You pay per request (on-demand mode) or provision read/write capacity units (provisioned mode with auto-scaling).

Data model: tables contain items (equivalent to rows). Each item is a collection of attributes (key-value pairs, JSON-like). The primary key is either: simple (partition key only) or composite (partition key + sort key). The partition key determines which DynamoDB partition stores the item. Items with the same partition key and different sort keys are stored together, enabling efficient range queries.

Single-table design: DynamoDB works best when you put multiple entity types (users, orders, products) in one table with a generic PK/SK schema (PK: USER#123, SK: ORDER#456). This enables fetching related entities in one query using Query on the same partition. Over-normalization into multiple tables means multiple API calls to load related data — expensive and slow.

Global Secondary Indexes (GSI): project items onto an alternative key schema, enabling queries on non-primary-key attributes. Example: table with PK=userID, SK=orderDate; GSI with PK=status, SK=orderDate queries all pending orders sorted by date. GSIs have their own read/write capacity and are eventually consistent. LSIs (Local Secondary Indexes) share the main table's partition key and are strongly consistent but must be created at table creation time.

Capacity modes: provisioned mode sets read capacity units (RCU) and write capacity units (WCU). One RCU = one strongly consistent read of up to 4KB/second; one WCU = one write of up to 1KB/second. On-demand mode removes capacity planning — ideal for unpredictable traffic. Switch between modes up to twice per day.

Transactions: TransactWriteItems allows up to 100 items across one or more tables to be written atomically. All succeed or all fail — essential for operations like transferring credits between users. Conditional writes use ConditionExpression to write only if an attribute has a specific value, enabling optimistic locking without explicit transaction overhead.

DynamoDB Streams records item-level changes (INSERT, MODIFY, REMOVE) as an ordered log, available for 24 hours. Lambda can process stream events for: replicating changes to Elasticsearch, triggering notifications on order status changes, maintaining aggregate counts. Streams + Lambda = event-driven data pipelines without polling.

Architecture Diagram

Users / clients
         |
  DynamoDB
         |
  Core services
         |
  Data + observability

Examples

bash 
# DynamoDB
# Single-table design, GSIs, on-demand vs provisioned.
# Validate in staging before production rollout.

Key Concepts

Data modelHow DynamoDB structures and queries data
ConsistencyGuarantees under failure and replication
Scaling axisVertical vs horizontal growth patterns
OpsBackup, monitoring, and upgrade path

Interview Questions

What problem does DynamoDB solve?

It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.

Key components of DynamoDB?

Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.

Common production pitfalls?

Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.

How do you test changes safely?

Staging parity, canary/gradual rollout, automated health checks, and documented rollback.

Metrics to prove success?

Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.

Beginner vs advanced concern?

Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.

Best Practices

  • Treat DynamoDB config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials.

Common Mistakes

  • Adopting DynamoDB without measurable success criteria.
  • No staging environment mirroring production constraints.
  • Missing rollback path during incidents.
  • Undocumented on-call expectations.

Cheat Sheet

DynamoDBSingle-table design, GSIs, on-demand vs provisioned.
SLOService level objective
RollbackRevert to last known good
CanaryLimited blast-radius rollout
RunbookIncident steps

Practical Exercises

DynamoDB sandbox

Stand up DynamoDB locally or in free tier; document commands and failure recovery.

Failure drill

Introduce misconfiguration; practice detection and rollback under time limit.

← Cassandra

Related topics