DynamoDB

DynamoDB is AWS's serverless key-value store. You don't run servers, choose instance sizes or plan shards: tables scale by partitioning automatically, and reads by key stay fast whether the table holds a megabyte or a petabyte. The price is that you design around known access patterns, much like Cassandra.

When to reach for it

• Access is by key: get a user's session, a short link, a cart, a device's latest state.
• Traffic is large or spiky and you want no capacity planning or operations.
• You're on AWS and want built-in replication across zones, backups and global tables.

If queries are ad hoc, need joins or aggregate across many items, Postgres or a warehouse fits better.

Data model

Every item has a primary key:

• A partition key alone, such as link_code, for pure key-value lookups.
• A partition key plus a sort key, such as user_id + created_at, so one partition holds many items sorted for range queries: "this user's orders, newest first".

Items are schemaless documents up to 400 KB. Store larger payloads in S3 and keep a pointer.

Secondary indexes

• A global secondary index (GSI) re-keys the table by other attributes, such as orders by status + created_at. It's updated asynchronously, so reads from it are eventually consistent, and it has its own throughput.
• A local secondary index (LSI) keeps the same partition key with a different sort key; it must be created with the table.

Design indexes from the queries you need, not from the fields you have.

Single-table design

Experienced DynamoDB users often store several entity types in one table, with generic keys like PK = USER#42 and SK = ORDER#2026-10-17. One Query then fetches a user and their recent orders together. It's powerful for fixed, high-volume access patterns, and painful when patterns change, so in an interview mention it only if you can explain the keys.

Capacity and numbers

Latency for key readsmicroseconds with DAX cache

single-digit ms

Per-partition limitper physical partition

~3,000 reads/s and ~1,000 writes/s

Item size limit

400 KB

Capacity modes

on-demand or provisioned with autoscaling

The per-partition limit is the one to remember: a single hot partition key, such as one celebrity's counter, can't exceed it no matter how big the table is. Spread hot keys with suffixes or cache them.

Consistency and transactions

• Reads are eventually consistent by default; ask for strongly consistent reads on the base table when needed, at double the read cost.
• Conditional writes (attribute_not_exists(pk), version = :expected) give optimistic concurrency and uniqueness.
• Transactions cover up to 100 items across tables, all or nothing.
• Streams emit every change, for CDC into search indexes, analytics or triggers.
• Global tables replicate across regions, active-active with last-writer-wins conflict resolution.

Try it

URL Shortener HLD

Store and serve short links at scale.