DynamoDB

DynamoDB is AWS's fully-managed, serverless key-value and document database. Its promise is predictable single-digit-millisecond latency at essentially any scale, with no servers to run and no capacity planning if you use on-demand mode. When you want a store that just scales and you're happy to design around its access model, it's a strong default on AWS.

The key model

Every item has a primary key, in one of two shapes:

• Partition key only — a pure key-value lookup (user_id → the user).
• Partition key + sort key — items sharing a partition key are stored together, ordered by the sort key. This is what makes range queries work: "all orders for this user, newest first" is partition = user_id, query the sort key.

The partition key determines which physical partition (and node) holds the item — pick it so your reads hit one partition and so load spreads evenly across keys.

Single-table design

Like Cassandra, Dynamo rewards modeling around queries rather than entities — often one table holding multiple entity types, with carefully chosen keys so each access pattern is a single query. For other access patterns you add secondary indexes:

• Local secondary index (LSI): same partition key, a different sort key.
• Global secondary index (GSI): a completely different partition/sort key — effectively a second, async-maintained view of the table.

You design the keys and indexes up front from your query list; ad-hoc queries aren't the point.

Nice built-ins

• Streams — a change log of every write, which you can feed to Lambda (for derived tables, search indexing, or event-driven work) — change-data-capture, built in.
• TTL — items auto-expire, great for sessions and ephemeral data.
• On-demand scaling — no capacity to provision; it absorbs spikes.
• Transactions — limited multi-item transactions when you need them.

What to watch

• Access patterns must be known up front. New query shapes often mean a new GSI and a backfill. This is the big mental adjustment from SQL.
• Hot partitions. A partition key that concentrates traffic (a single trending item, a sequential key) creates a hotspot; design keys to spread load.
• Cost model. You pay per read/write unit and for storage; a scan or a badly-keyed access pattern can get expensive. It rewards precise key design.
• AWS lock-in. It's an AWS service; portability is a consideration.

Dynamo vs Cassandra

They share DNA — wide partition model, query-first design, horizontal scale. The practical difference: DynamoDB is fully managed (you run nothing) and AWS-only; Cassandra is open-source (you run it, or use a managed flavour) and portable. On AWS, Dynamo is usually the lower-ops choice.

What to say in an interview

Use it for key-based access at scale with low ops, designing keys from the queries:

"I'd store the session and user-profile data in DynamoDB — key-value access at single-digit-ms latency with nothing to operate. The partition key is user_id; for 'a user's recent activity' I'd use user_id + a timestamp sort key. A GSI covers lookups by email. Dynamo Streams would feed changes into search indexing. It's AWS-only, which I'd flag as a trade-off."

---

Next up: PostgreSQL — the relational default that scales further than people think.