Courses › System Design › Key Technologies

DynamoDB

Partition/sort keys, GSIs, capacity modes, transactions and streams.

Amazon DynamoDB is a fully managed key-value and document database. It offers predictable single-digit-millisecond performance at virtually any scale with almost no operational work. In interviews, it's a strong choice when access patterns are key-based and you want to scale without running a cluster.

Data model

  • Table — a collection of items (rows), each up to 400 KB.
  • Partition key — hashed to choose the physical partition. Required.
  • Sort key — optional; orders items within a partition and enables range queries.
  • Together they form the primary key.
PK = USER#42     SK = ORDER#2026-10-01#9001   → order item
PK = USER#42     SK = ORDER#2026-10-07#9022   → order item
PK = ORDER#9001  SK = ITEM#1                   → line item

Query PK = USER#42, SK begins_with ORDER#2026-10 returns a user's October orders, already sorted.

Secondary indexes

  • Global Secondary Index (GSI) — a different partition and sort key over the same data, maintained asynchronously (eventually consistent). Use it for alternate access patterns, like "orders by status."
  • Local Secondary Index (LSI) — same partition key, different sort key. Must be defined at table creation.

Capacity and partitions

  • On-demand mode scales automatically and bills per request — a good default for spiky or unknown traffic.
  • Provisioned mode with auto-scaling is cheaper for steady workloads.
  • Each partition has throughput limits (roughly 3,000 reads/s and 1,000 writes/s), so a hot partition key throttles even when the table has capacity overall. Choose high-cardinality keys, and shard hot keys with a suffix.

Consistency and transactions

  • Reads are eventually consistent by default; strongly consistent reads are available on the base table (not on GSIs) at twice the read cost.
  • Conditional writes (ConditionExpression: attribute_not_exists(PK) or status = :available) provide compare-and-set — the main tool for contention problems.
  • Transactions (TransactWriteItems) cover up to 100 items across tables, all-or-nothing.

Other features worth mentioning

  • TTL — automatically delete items after an expiry timestamp (sessions, reservations, ephemeral data).
  • DynamoDB Streams — an ordered change log per item, for triggering Lambda functions, syncing to Elasticsearch, or building materialized views.
  • Global Tables — multi-region, multi-active replication with last-writer-wins conflict resolution.
  • DAX — an in-memory cache in front of DynamoDB for microsecond reads.

When to use it

  • Key-based access patterns known up front
  • Very high or very spiky scale with minimal ops
  • Serverless architectures on AWS

When not to

  • Ad-hoc queries, analytics, or complex joins
  • Many evolving access patterns that would each need a GSI
  • Items larger than 400 KB (store blobs in S3 and keep a pointer)

[!INTERVIEW] Reservation with a conditional write "To hold a seat, I'll do a conditional PutItem on PK=EVENT#77, SK=SEAT#A12 with attribute_not_exists(PK) OR expires_at < :now, and a TTL so expired holds clean themselves up. DynamoDB guarantees only one writer wins."