Amazon DynamoDB - Serverless NoSQL at Scale

What you will learn

• What DynamoDB is and when NoSQL is the right choice over relational databases
• Tables, items, attributes — and how flexible schema actually works in practice
• Primary key design — Partition Key only vs Partition Key + Sort Key
• Why partition key selection determines the performance ceiling of your entire table
• On-Demand vs Provisioned capacity modes and when each saves money
• DAX — microsecond reads with zero application code changes
• DynamoDB Streams — the ordered changelog that powers event-driven architecture
• Global Tables — active-active multi-region replication and the Streams prerequisite
• TTL — automatic item expiry with zero extra cost
• PITR and on-demand backups for disaster recovery
• S3 export for analytics without consuming read capacity

Why this matters

Hotstar serves metadata for millions of videos — episode details, thumbnails, descriptions. The access pattern is simple: get video by ID. The scale is massive: millions of reads per second with single-digit millisecond response time required. RDS cannot handle this without enormous cost and operational complexity. CRED stores user reward points and transaction history — flexible schema evolves as the product adds new reward types without schema migrations. PhonePe processes UPI transactions where session tokens must expire automatically after 10 minutes — TTL handles this at zero cost. DynamoDB is not a replacement for relational databases. It is the correct choice when the access pattern is simple, the scale is massive, and the schema evolves rapidly.

What is DynamoDB and When to Use It

DynamoDB is AWS's fully managed proprietary NoSQL database. Millisecond latency at any scale, serverless, Multi-AZ by default. No schema enforcement — each item can have different attributes.

DynamoDB vs RDS — when to choose which:

Tables, Items, Attributes, and Primary Keys

Key terms:

Flexible attributes in practice:

Item 2 has phone and city but no email. Item 3 has score, level, and a list of badges. All in the same table, no errors. This is why DynamoDB enables rapid schema evolution — new attributes just appear on new items.

Data types:

Primary Key — decided at table creation, cannot be changed:

Two options:

Game scores table example:

User-002 appears twice — same user played two games. The UserId + GameId combination is unique so both rows are valid. Sort Key allows one entity to have many related items in the same table.

Partition Key Design — The Most Critical Decision

The partition key determines which physical partition holds your data. A poor choice causes hot partitions — one partition gets all the traffic while others sit idle. This is the most common DynamoDB performance mistake.

Common Mistake

Using a low-cardinality value like Status or Country as the partition key. If 90% of your writes have Status=active, then 90% of your writes go to a single partition. DynamoDB throttles that partition. Your application sees errors. Fix by choosing a high-cardinality attribute like UserId or using partition key sharding.

Read and Write Capacity Modes

On-Demand Mode:

DynamoDB automatically scales reads and writes up and down instantly. No capacity planning needed.

Provisioned Mode:

You specify upfront how many reads per second (RCU) and writes per second (WCU).

Tip

Start with On-Demand for new applications — no guessing required. Once you understand your traffic pattern after a few weeks, switch to Provisioned with Auto Scaling to save cost.

DAX — DynamoDB Accelerator

DynamoDB responds in single-digit milliseconds. For read-heavy applications hitting the same data constantly — a leaderboard, product catalog, popular items — those milliseconds add up and the database gets congested with repeated reads.

DAX is a fully managed in-memory cache specifically for DynamoDB. Frequently accessed data is returned in microseconds — up to 10x faster than going to DynamoDB directly.

No application code changes needed:

DAX uses the same DynamoDB API. You point your SDK at the DAX cluster endpoint instead of the DynamoDB endpoint. Everything else stays the same.

DAX vs ElastiCache for DynamoDB:

Tip

For DynamoDB read caching, always try DAX first. It requires no code changes and gives microsecond reads. Only reach for ElastiCache if you need to cache something DAX cannot — like an aggregated result computed across many items.

DynamoDB Streams

Every time an item is created, updated, or deleted, DynamoDB Streams captures that change as an ordered event. Think of it as a real-time changelog of everything that happened in your table.

Two ways to consume streams:

Full stream processing pattern:

Global Tables — Active-Active Multi-Region

Global Tables makes your DynamoDB table available in multiple regions simultaneously with active-active replication — writes accepted in any region, replicated everywhere.

Both regions are fully active. A user in Mumbai reads from and writes to the Mumbai replica with single-digit millisecond latency. A user in New York does the same against the Virginia replica.

DynamoDB Streams must be enabled before creating Global Tables:

Global Tables uses Streams internally as the replication engine — every change recorded in Streams is what gets replicated to other regions.

Remember

DynamoDB Streams is a hard prerequisite for Global Tables. If you try to create a Global Table without Streams enabled, it fails. Enable Streams first, always.

Global Tables vs RDS Cross-Region Read Replica:

TTL — Time To Live

TTL automatically deletes items from your table after a set time. No cleanup code, no scheduled jobs, no extra cost.

How it works:

Session management example:

Split sensitive data to protect it from TTL deletion:

Session expires → only the Sessions row deletes. User profile stays safe in the Users table.

Backups for Disaster Recovery

PITR — Point In Time Recovery (continuous backup):

On-Demand Backups:

S3 Export — analytics without consuming RCU:

Hands-on Lab — Create Table, Insert Items, Enable TTL and Streams

Step 1 — Create a DynamoDB table

Step 2 — Add items

Step 3 — Query for one user

Step 4 — Enable TTL

Step 5 — Enable DynamoDB Streams

Step 6 — Enable PITR

Step 7 — Cleanup

Production Best Practices and Common Pitfalls

• Choose a high-cardinality partition key — the partition key determines data distribution and is the single most important table design decision
• Use Query not Scan — Scan reads every item in the table and filters after, extremely expensive at scale. Design access patterns around Query
• Enable PITR on every production table from day one — accidental deletes happen and you cannot recover without it
• Enable Streams before adding Global Tables — it is a hard prerequisite and cannot be added retroactively to an existing Global Table
• Start with On-Demand capacity for new tables — switch to Provisioned with Auto Scaling once traffic is predictable
• Store large objects in S3 and save only the S3 URL in DynamoDB — maximum item size is 400 KB, images and documents do not belong in DynamoDB
• Use TTL for any data with a natural expiry — session tokens, temporary codes, cache entries — zero cost, zero cleanup code needed

Quick Reference and Troubleshooting Commands

Common problems and fixes:

Common Mistake

Using Scan instead of Query. Scan reads every single item in the table and then filters results in memory. On a 10 million item table this consumes enormous read capacity, takes seconds, and gets progressively worse as the table grows. Always design your access patterns around Query using the primary key. If you find yourself writing Scans in production code, your table design needs rethinking.

Common Mistake

Choosing DynamoDB for everything. DynamoDB is excellent at scale with simple access patterns. It is terrible for ad-hoc reporting, complex joins, and ACID transactions across multiple entities. A Zerodha-style trading ledger needs relational integrity — DynamoDB cannot replace that. Always choose the database based on the access pattern, not familiarity.

Security

DynamoDB Global Tables use last-writer-wins for conflict resolution. If two users in different regions update the same item within milliseconds of each other, the last write wins and the other is lost. Design your application to avoid concurrent writes to the same item from multiple regions, or use conditional writes to detect and handle conflicts explicitly.

Common Mistakes to Avoid

Common Mistake

Using Scan instead of Query. Scan reads every single item in the table and then filters. On a 10-million-item table this is slow and expensive. Design access patterns around Query using the primary key from day one.

Common Mistake

Choosing a low-cardinality partition key like Status or Country. If 90% of writes have Status=active, 90% of writes hit one partition. DynamoDB throttles it. Use a high-cardinality key like UserId or OrderId.

Common Mistake

Choosing DynamoDB for everything. DynamoDB is excellent for simple key-based access at massive scale. It is wrong for complex joins, relational integrity, and ad-hoc reporting. Choose the database based on the access pattern.