Index/DynamoDB

SponsorGitHub
Key technologyManaged KV store3 min

DynamoDB

Key-value and document storage with flat latency at any size, as long as you design for the key.

At a glance

Model
Partition key, optional sort key; items up to 400 KB
Latency
Single-digit milliseconds at a thousand items or a trillion
Reads
Eventually consistent by default; strongly consistent costs twice
Capacity
On-demand absorbs spikes; provisioned is cheaper when steady
Concurrency
Conditional writes, and transactions across up to 100 items
Change feed
Streams, ordered per partition key, kept 24 hours

Key concepts and capabilities

The short listwhat it gives you
Query by key only — GetItem by exact key, Query on a partition key plus a sort-key condition; Scan is the wrong answer
Indexes are decided up front — a GSI is a second copy with its own key, updated asynchronously; an LSI is strongly consistent
Single-table design — PK=USER#123, SK=ORDER#… packs related entities so one Query returns them together
Conditional writes — attribute_not_exists for insert-if-absent, version = :expected for optimistic concurrency
Transactions — TransactWriteItems is all-or-nothing across up to 100 items, at twice the cost
Streams — every change published in order per key, which is how you avoid dual writes
TTL deletes expired items in the background for free: sessions, carts, rate-limit buckets
Hot partitions throttle even when the table has capacity — spread the key or bucket by time
Cost is request units — a write unit is 1 KB, a read unit 4 KB eventually consistent; reason in those out loud

Use cases

One table, one round trip

There are no joins, so related entities are packed under one partition key and retrieved together: PK=USER#123 with a sort key range between ORDER# and ORDER#~ returns the profile and the recent orders in a single Query. It reads strangely and it is the idiomatic pattern.

primary or partition keysort keynullable

Exactly-once without a lock

A conditional write is the concurrency primitive: PutItem with attribute_not_exists(pk) succeeds for the first caller and fails for every retry, which is an idempotency key, a username claim or a lock, depending on what you put in the key.

FocusClick a node for details

Fanning changes out with Streams

Every change can be published in order per partition key and kept for 24 hours. That stream is how a search index, an aggregate or a notification is driven from the table without the application writing to two places and getting them out of step.

DatabaseQueue / streamFocusClick a node for details

Spreading a hot partition

Traffic concentrated on one partition key is throttled even though the table has capacity, because a partition has its own ceiling. The fix is in the key: add a suffix and fan the reads across it, or bucket by time so today's writes are not all one key.

FocusClick a node for details