Chapter 1: Introduction and Origins

Amazon DynamoDB represents a paradigm shift in how we think about databases in the cloud. Its lineage traces back to a critical business decision at Amazon in the mid-2000s: that losing a customer’s shopping cart during peak traffic was an unacceptable business outcome, even if it meant relaxing traditional database consistency guarantees. This decision led to the original Dynamo paper (2007), one of the most influential distributed systems papers ever written, which in turn inspired not only DynamoDB but also Apache Cassandra, LinkedIn’s Voldemort, and Riak. DynamoDB itself, launched in 2012, took Dynamo’s core insights and wrapped them in a fully managed service that eliminated the significant operational burden of running a distributed database. Today it is one of the most widely used NoSQL databases, powering everything from gaming leaderboards to e-commerce catalogs to IoT data streams, and processing trillions of requests per day across Amazon’s own services and external AWS customers.

Chapter Goals:

Understand the Dynamo paper and its influence on DynamoDB
Learn the design goals and requirements for DynamoDB
Grasp the key differences between Dynamo and DynamoDB
Appreciate the workload characteristics DynamoDB was built for

The Origins: Amazon’s Availability Challenge

The Shopping Cart Problem (2004-2005)

In the mid-2000s, Amazon faced a critical challenge that would reshape database design. Werner Vogels, Amazon’s CTO, later described the situation: during peak shopping periods, even brief database unavailability translated directly into lost revenue. The existing relational databases (Oracle, MySQL) provided strong consistency guarantees, but at the cost of availability during network partitions or heavy load. Amazon’s engineers realized they needed to fundamentally rethink the trade-offs:

┌────────────────────────────────────────────────────────────┐
│              AMAZON'S SHOPPING CART CRISIS                 │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  THE PROBLEM:                                              │
│  ┌──────────────────────────────────────────────────┐     │
│  │ Peak Holiday Shopping (Black Friday/Cyber Monday) │     │
│  │                                                    │     │
│  │ • Millions of concurrent users                     │     │
│  │ • Shopping cart must ALWAYS be available           │     │
│  │ • Losing a cart = Lost revenue                     │     │
│  │ • Database outages = Unacceptable                  │     │
│  │                                                    │     │
│  │ Traditional RDBMS Issues:                          │     │
│  │ • Master-slave replication creates single point    │     │
│  │ • Network partitions cause unavailability          │     │
│  │ • Scaling vertically hits limits                   │     │
│  │ • Can't sacrifice consistency for availability     │     │
│  └──────────────────────────────────────────────────┘     │
│                                                            │
│  THE REQUIREMENT:                                          │
│  "The shopping cart must be available for writes           │
│   even during network partitions, database failures,       │
│   or datacenter outages"                                   │
│                                                            │
│  THE INSIGHT:                                              │
│  It's better to show a customer a slightly stale           │
│  shopping cart than to show them an error page             │
│                                                            │
└────────────────────────────────────────────────────────────┘

The CAP Theorem Dilemma

Amazon engineers confronted the fundamental CAP theorem constraint:

CAP Theorem Refresher

CAP Theorem: In a distributed system, you can have at most TWO of:

┌──────────────────────────────────────┐
│        CAP THEOREM TRIANGLE          │
│                                      │
│              Consistency             │
│                  ╱ ╲                 │
│                 ╱   ╲                │
│                ╱     ╲               │
│               ╱       ╲              │
│              ╱         ╲             │
│             ╱           ╲            │
│            ╱             ╲           │
│           ╱   Choose 2   ╲          │
│          ╱                 ╲         │
│         ╱                   ╲        │
│        ╱                     ╲       │
│   Availability ─────────── Partition │
│                             Tolerance │
│                                      │
│  Traditional RDBMS: CP               │
│  Dynamo/DynamoDB: AP                 │
└──────────────────────────────────────┘

Consistency (C): All nodes see the same data at the same time Availability (A): Every request receives a response (success or failure) Partition Tolerance (P): System continues operating despite network failuresSince network partitions WILL happen in distributed systems, you must choose between C and A.

Amazon's Choice: Availability Over Consistency

Amazon’s Decision:

Traditional E-commerce Database (CP):
┌─────────────────────────────────────┐
│ Network Partition Occurs            │
│                                     │
│ Master DB    ╳╳╳╳╳    Slave DB     │
│ (can't sync)         (can't write) │
│                                     │
│ Result: DENY WRITES                 │
│ Customer Impact: "Service Unavail"  │
│ Business Impact: LOST SALES         │
└─────────────────────────────────────┘

Amazon's Dynamo Approach (AP):
┌─────────────────────────────────────┐
│ Network Partition Occurs            │
│                                     │
│ Node A       ╳╳╳╳╳      Node B     │
│ (accepts writes)  (accepts writes) │
│                                     │
│ Result: BOTH ACCEPT WRITES          │
│ Customer Impact: Shopping continues │
│ Business Impact: NO LOST SALES      │
│                                     │
│ Conflict Resolution: Merge later    │
│ (More items in cart is acceptable)  │
└─────────────────────────────────────┘

Key Insight: For shopping carts, it’s better to have duplicate items (which can be deduplicated at checkout) than to refuse the add-to-cart operation.

The Dynamo Paper (2007)

Paper Overview

In 2007, Amazon published “Dynamo: Amazon’s Highly Available Key-value Store” at SOSP (Symposium on Operating Systems Principles). Authored by Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, and others, this paper was a landmark because it synthesized several existing distributed systems techniques (consistent hashing, vector clocks, quorum protocols, gossip, Merkle trees) into a coherent, production-tested system with clear trade-off rationale. The paper was remarkably honest about the operational complexities of the system, which made it both practically useful and academically influential.

┌───────────────────────────────────────────────────────────┐
│           DYNAMO PAPER - KEY CONTRIBUTIONS                │
├───────────────────────────────────────────────────────────┤
│                                                           │
│  1. CONSISTENT HASHING                                    │
│     Problem: How to distribute data across many nodes?    │
│     Solution: Hash ring for even distribution             │
│                                                           │
│  2. EVENTUAL CONSISTENCY                                  │
│     Problem: How to stay available during partitions?     │
│     Solution: Accept conflicts, resolve later             │
│                                                           │
│  3. VECTOR CLOCKS                                         │
│     Problem: How to detect conflicting writes?            │
│     Solution: Track causality with version vectors        │
│                                                           │
│  4. GOSSIP PROTOCOL                                       │
│     Problem: How do nodes discover each other?            │
│     Solution: Peer-to-peer membership via gossip          │
│                                                           │
│  5. HINTED HANDOFF                                        │
│     Problem: How to handle temporary node failures?       │
│     Solution: Store hints for downed nodes                │
│                                                           │
│  6. ANTI-ENTROPY WITH MERKLE TREES                        │
│     Problem: How to detect and repair data divergence?    │
│     Solution: Efficient comparison with Merkle trees      │
│                                                           │
│  7. SLOPPY QUORUM                                         │
│     Problem: How to balance consistency and availability? │
│     Solution: Read and write quorums with tunable N, R, W │
│                                                           │
└───────────────────────────────────────────────────────────┘

Dynamo Design Principles

Dynamo’s Core Principles:

Always writable: Sacrifice consistency for availability
Incremental scalability: Add one node at a time
Symmetry: All nodes have same responsibilities (no master)
Decentralization: No central coordination
Heterogeneity: Support different hardware capabilities
Simple interface: Get/Put operations on keys

Dynamo Architecture Overview

┌────────────────────────────────────────────────────────────┐
│               ORIGINAL DYNAMO ARCHITECTURE                 │
│                   (2007 Paper)                             │
└────────────────────────────────────────────────────────────┘

Request Flow:
┌─────────────┐
│   Client    │
└──────┬──────┘
       │ put("key123", "value")
       ↓
┌─────────────────────────────────────────────────────────────┐
│              CONSISTENT HASH RING                           │
│                                                             │
│         Node A                    Node B                    │
│         (0-90°)                   (90-180°)                 │
│            │                         │                      │
│            │    Node F        Node C │                      │
│            │   (270-360°)   (180-270°)                      │
│            │        │           │    │                      │
│            └────────┼───────────┼────┘                      │
│                     │           │                           │
│                  Node E      Node D                         │
│                                                             │
│  hash("key123") → 95° → Node B is coordinator              │
│                                                             │
│  Replication: N = 3 (store on 3 nodes)                     │
│  - Primary: Node B                                          │
│  - Replica 1: Node C (next clockwise)                      │
│  - Replica 2: Node D (next clockwise)                      │
└─────────────────────────────────────────────────────────────┘

Write Path with Quorum (W = 2):
┌──────────┐
│ Client   │ put("key123", "value")
└────┬─────┘
     │
     ↓
┌────────────┐ Coordinator receives write
│  Node B    │───────────────────────────┐
│(Coordinator)│                           │
└────┬───────┘                           │
     │                                   │
     ├─────────────┬─────────────┐       │
     ↓             ↓             ↓       │
┌─────────┐   ┌─────────┐   ┌─────────┐ │
│ Node B  │   │ Node C  │   │ Node D  │ │
│ (Write) │   │ (Write) │   │ (Write) │ │
└────┬────┘   └────┬────┘   └────┬────┘ │
     │             │             │       │
     │  ACK 1      │  ACK 2      │       │
     └─────────────┴─────────────┘       │
                   │                     │
                   ↓                     │
              W=2 achieved               │
            (2 out of 3 ACKs)            │
                   │                     │
                   ↓                     │
            Return SUCCESS ←─────────────┘

Read Path with Quorum (R = 2):
┌──────────┐
│ Client   │ get("key123")
└────┬─────┘
     │
     ↓
┌────────────┐
│  Node B    │ Coordinator requests from 3 nodes
│(Coordinator)│
└────┬───────┘
     │
     ├─────────────┬─────────────┐
     ↓             ↓             ↓
┌─────────┐   ┌─────────┐   ┌─────────┐
│ Node B  │   │ Node C  │   │ Node D  │
│ v1 (t1) │   │ v2 (t2) │   │ v1 (t1) │
└────┬────┘   └────┬────┘   └────┬────┘
     │             │             │
     └─────────────┴─────────────┘
                   │
                   ↓
          R=2 achieved (2 responses)
          Conflict detected: v1 vs v2
                   │
                   ↓
          Read Repair: Sync to latest
          Return v2 to client

From Dynamo to DynamoDB

The Evolution (2007-2012)

Amazon used internal Dynamo for years before creating DynamoDB as a managed service. The evolution from Dynamo to DynamoDB is a fascinating case study in how operational experience reshapes system design. While Dynamo was technically elegant, running it in production required significant expertise: teams had to tune N/R/W quorum parameters, handle application-level conflict resolution, manage gossip protocol configuration, and perform manual capacity planning. DynamoDB addressed these pain points by making opinionated default choices and automating operations, trading fine-grained control for ease of use:

┌───────────────────────────────────────────────────────────┐
│           DYNAMO → DYNAMODB EVOLUTION                     │
├───────────────────────────────────────────────────────────┤
│                                                           │
│  2007: Dynamo Paper Published                             │
│  │                                                         │
│  ├─→ Used internally for shopping cart                   │
│  ├─→ Inspired Apache Cassandra (open source)             │
│  ├─→ Inspired LinkedIn Voldemort                          │
│  │                                                         │
│  2009-2011: Operational Challenges                        │
│  │                                                         │
│  ├─→ Complex to operate and tune                         │
│  ├─→ Operational burden on teams                          │
│  ├─→ Different teams reimplementing similar systems       │
│  │                                                         │
│  2012: DynamoDB Launched (AWS re:Invent)                  │
│  │                                                         │
│  └─→ Fully managed service                               │
│      └─→ No operational burden                           │
│      └─→ Automatic scaling                               │
│      └─→ Single-digit millisecond latency                │
│      └─→ SLA guarantees                                   │
│                                                           │
└───────────────────────────────────────────────────────────┘

Key Differences: Dynamo vs DynamoDB

Architecture
Consistency
Conflict Resolution

Dynamo (2007) vs DynamoDB (2012+)

┌────────────────────────────────────────────────────┐
│              ARCHITECTURE COMPARISON                │
├────────────────────────────────────────────────────┤
│                                                    │
│  DYNAMO (Internal System):                         │
│  ┌──────────────────────────────────────────────┐ │
│  │ • Peer-to-peer (no master)                   │ │
│  │ • Symmetric nodes                            │ │
│  │ • Gossip-based membership                    │ │
│  │ • Client chooses coordinator                 │ │
│  │ • Vector clocks for versioning               │ │
│  │ • Application resolves conflicts             │ │
│  │ • Manual scaling and operations              │ │
│  └──────────────────────────────────────────────┘ │
│                                                    │
│  DYNAMODB (Managed Service):                       │
│  ┌──────────────────────────────────────────────┐ │
│  │ • Request router layer                       │ │
│  │ • Separate storage nodes                     │ │
│  │ • Managed control plane                      │ │
│  │ • AWS handles routing                        │ │
│  │ • Last-write-wins conflict resolution        │ │
│  │ • AWS resolves conflicts automatically       │ │
│  │ • Fully automated operations and scaling     │ │
│  └──────────────────────────────────────────────┘ │
│                                                    │
└────────────────────────────────────────────────────┘

Consistency Models

DYNAMO:
┌────────────────────────────────────────┐
│ Tunable Consistency (N, R, W)          │
│                                        │
│ N = Replication factor                 │
│ R = Read quorum                        │
│ W = Write quorum                       │
│                                        │
│ Common configurations:                 │
│ • N=3, R=2, W=2 (quorum)              │
│ • N=3, R=1, W=3 (fast reads)          │
│ • N=3, R=3, W=1 (fast writes)         │
│                                        │
│ If R + W > N: Strong consistency       │
│ If R + W ≤ N: Eventual consistency     │
└────────────────────────────────────────┘

DYNAMODB:
┌────────────────────────────────────────┐
│ Two Consistency Levels                 │
│                                        │
│ Eventually Consistent Reads (default): │
│ • May return stale data                │
│ • Lower latency                        │
│ • Half the read cost                   │
│                                        │
│ Strongly Consistent Reads (opt-in):    │
│ • Always return latest data            │
│ • Higher latency                       │
│ • Double the read cost                 │
│ • Not available on GSI                 │
│                                        │
│ All writes are strongly consistent     │
└────────────────────────────────────────┘

How Conflicts Are Handled

DYNAMO (2007):
┌─────────────────────────────────────────────┐
│ Application-Level Conflict Resolution      │
│                                             │
│ 1. Vector clocks track causality           │
│                                             │
│    Write 1: {A:1} → "item: laptop"         │
│    Write 2: {B:1} → "item: laptop, mouse"  │
│                                             │
│ 2. Read returns BOTH conflicting versions  │
│                                             │
│    get("cart") → [                         │
│      {value: "laptop", vclock: {A:1}},     │
│      {value: "laptop, mouse", vclock:{B:1}}│
│    ]                                        │
│                                             │
│ 3. Application merges (shopping cart)      │
│                                             │
│    merged = union(v1, v2)                  │
│    = "laptop, mouse"                       │
│                                             │
│ 4. Write back with reconciled vclock       │
│                                             │
│    put("cart", merged, {A:1, B:1})         │
└─────────────────────────────────────────────┘

DYNAMODB (2012+):
┌─────────────────────────────────────────────┐
│ Last-Write-Wins (LWW) Conflict Resolution  │
│                                             │
│ 1. Each write has timestamp                │
│                                             │
│    Write 1 (t=100): "laptop"               │
│    Write 2 (t=101): "laptop, mouse"        │
│                                             │
│ 2. Read returns ONLY latest by timestamp   │
│                                             │
│    get("cart") → "laptop, mouse"           │
│                                             │
│ 3. Earlier write is LOST                   │
│                                             │
│    If writes happen simultaneously:        │
│    - One arbitrarily wins                  │
│    - Other is lost                         │
│                                             │
│ 4. Application must handle at app layer    │
│                                             │
│    Option 1: Use conditional writes        │
│    Option 2: Use transactions              │
│    Option 3: Accept loss (e.g., counters)  │
└─────────────────────────────────────────────┘

Why DynamoDB Changed Design

Simplification for Managed Service

Operational Complexity vs Developer Experience

DYNAMO Challenges (Peer-to-Peer):
┌────────────────────────────────────────┐
│ Complex Operations:                    │
│ • Gossip protocol configuration        │
│ • Manual membership management         │
│ • Tuning N, R, W for each table        │
│ • Application conflict resolution      │
│ • Manual failure detection             │
│ • Compaction and repair operations     │
│                                        │
│ Result: High barrier to entry          │
└────────────────────────────────────────┘

DYNAMODB Solution (Managed Service):
┌────────────────────────────────────────┐
│ AWS Handles Complexity:                │
│ • Automatic membership                 │
│ • Transparent routing                  │
│ • Simple consistency choice (2 options)│
│ • Automatic conflict resolution (LWW)  │
│ • Automatic failure handling           │
│ • Managed maintenance                  │
│                                        │
│ Result: Focus on application logic     │
└────────────────────────────────────────┘

Trade-off: Simplicity and ease of use vs fine-grained control

Performance Predictability

Deterministic PerformanceDynamo’s peer-to-peer architecture had variable performance:

Coordinator selection affected latency
Gossip delays caused inconsistent routing
Vector clock size grew unbounded

DynamoDB’s managed architecture provides:

Predictable single-digit millisecond latency
SLA guarantees (99.99% availability)
Consistent performance across regions
Bounded conflict resolution time

Multi-Tenancy Requirements

Shared Infrastructure at AWS Scale

DYNAMO (Single Tenant):
┌─────────────────────────────────────┐
│ One cluster per service/team        │
│ • Dedicated resources               │
│ • Custom configuration              │
│ • Manual capacity planning          │
└─────────────────────────────────────┘

DYNAMODB (Multi-Tenant):
┌─────────────────────────────────────┐
│ Thousands of customers per cluster  │
│ • Shared resources with isolation   │
│ • Standardized configuration        │
│ • Automatic capacity management     │
│ • Noisy neighbor protection         │
│ • Fair queuing and throttling       │
└─────────────────────────────────────┘

Multi-tenancy required:

Stronger isolation guarantees
Better resource accounting
Simpler operational model
Protection against abuse

DynamoDB Design Goals

Primary Requirements

When designing DynamoDB as a managed service, AWS established clear goals:

┌───────────────────────────────────────────────────────────┐
│            DYNAMODB DESIGN REQUIREMENTS                   │
├───────────────────────────────────────────────────────────┤
│                                                           │
│  1. PERFORMANCE                                           │
│     ┌─────────────────────────────────────────────┐      │
│     │ • Single-digit millisecond latency          │      │
│     │ • Predictable performance at any scale      │      │
│     │ • P99 latency guarantees                    │      │
│     └─────────────────────────────────────────────┘      │
│                                                           │
│  2. SCALABILITY                                           │
│     ┌─────────────────────────────────────────────┐      │
│     │ • Scale from zero to millions of requests   │      │
│     │ • No practical storage limits               │      │
│     │ • Automatic partitioning                    │      │
│     │ • Seamless scaling without downtime         │      │
│     └─────────────────────────────────────────────┘      │
│                                                           │
│  3. AVAILABILITY                                          │
│     ┌─────────────────────────────────────────────┐      │
│     │ • 99.99% availability SLA                   │      │
│     │ • Multi-AZ replication                      │      │
│     │ • No single points of failure               │      │
│     │ • Transparent failover                      │      │
│     └─────────────────────────────────────────────┘      │
│                                                           │
│  4. DURABILITY                                            │
│     ┌─────────────────────────────────────────────┐      │
│     │ • 11 nines of durability (99.999999999%)    │      │
│     │ • Synchronous replication across 3 AZs      │      │
│     │ • Automatic backups                         │      │
│     │ • Point-in-time recovery                    │      │
│     └─────────────────────────────────────────────┘      │
│                                                           │
│  5. FULLY MANAGED                                         │
│     ┌─────────────────────────────────────────────┐      │
│     │ • No servers to manage                      │      │
│     │ • Automatic scaling                         │      │
│     │ • Automatic software patching               │      │
│     │ • Built-in security                         │      │
│     │ • Continuous backups                        │      │
│     └─────────────────────────────────────────────┘      │
│                                                           │
│  6. FLEXIBLE                                              │
│     ┌─────────────────────────────────────────────┐      │
│     │ • Schemaless (flexible attributes)          │      │
│     │ • Secondary indexes                         │      │
│     │ • Streams for change data capture           │      │
│     │ • Transactions for ACID operations          │      │
│     └─────────────────────────────────────────────┘      │
│                                                           │
└───────────────────────────────────────────────────────────┘

Non-Goals (What DynamoDB is NOT)

Important Distinctions:DynamoDB is NOT:

A relational database (no joins, no SQL)
A graph database (limited relationship queries)
An analytics database (use Redshift instead)
A full-text search engine (use Elasticsearch instead)
A document store with rich querying (use MongoDB instead)

DynamoDB is optimized for:

Key-value access patterns
Known query patterns
High-throughput workloads
Low-latency requirements
Simple CRUD operations

Target Workloads and Use Cases

Ideal Workloads for DynamoDB

┌────────────────────────────────────────────────────────────┐
│             DYNAMODB SWEET SPOT WORKLOADS                  │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  ✓ HIGH-SCALE WEB APPLICATIONS                            │
│    ┌────────────────────────────────────────┐             │
│    │ • User profiles and sessions           │             │
│    │ • Shopping carts                       │             │
│    │ • Product catalogs                     │             │
│    │ • User preferences                     │             │
│    └────────────────────────────────────────┘             │
│                                                            │
│  ✓ GAMING                                                 │
│    ┌────────────────────────────────────────┐             │
│    │ • Player profiles and inventory        │             │
│    │ • Game state storage                   │             │
│    │ • Leaderboards                         │             │
│    │ • Session management                   │             │
│    └────────────────────────────────────────┘             │
│                                                            │
│  ✓ IOT AND TIME-SERIES DATA                              │
│    ┌────────────────────────────────────────┐             │
│    │ • Device telemetry                     │             │
│    │ • Sensor data streams                  │             │
│    │ • Metrics and events                   │             │
│    │ • Log aggregation                      │             │
│    └────────────────────────────────────────┘             │
│                                                            │
│  ✓ MOBILE APPLICATIONS                                    │
│    ┌────────────────────────────────────────┐             │
│    │ • User data sync                       │             │
│    │ • App state storage                    │             │
│    │ • Offline-first architectures          │             │
│    │ • Push notification state              │             │
│    └────────────────────────────────────────┘             │
│                                                            │
│  ✓ SERVERLESS APPLICATIONS                                │
│    ┌────────────────────────────────────────┐             │
│    │ • Lambda function state                │             │
│    │ • API backend storage                  │             │
│    │ • Event-driven workflows               │             │
│    │ • Microservices data storage           │             │
│    └────────────────────────────────────────┘             │
│                                                            │
└────────────────────────────────────────────────────────────┘

Real-World Examples

E-Commerce: Amazon
Gaming: Fortnite
IoT: Samsung SmartThings
Mobile: Lyft

Amazon.com Shopping Cart

Requirements:
┌──────────────────────────────────────────┐
│ • Millions of concurrent users           │
│ • Must be always available for writes    │
│ • Low latency (< 10ms)                   │
│ • Shopping cart can't be lost            │
│ • Peak traffic during sales events       │
└──────────────────────────────────────────┘

DynamoDB Data Model:
┌──────────────────────────────────────────┐
│ Table: ShoppingCarts                     │
│                                          │
│ PK: userId                               │
│ SK: CART#{timestamp}                     │
│                                          │
│ Attributes:                              │
│ {                                        │
│   "userId": "user-12345",                │
│   "items": [                             │
│     {                                    │
│       "productId": "prod-789",           │
│       "quantity": 2,                     │
│       "price": 29.99                     │
│     }                                    │
│   ],                                     │
│   "totalAmount": 59.98,                  │
│   "lastUpdated": 1673892000              │
│ }                                        │
└──────────────────────────────────────────┘

Access Patterns:
• GetItem: Get cart by userId
• PutItem: Update cart items
• UpdateItem: Add/remove single item
• Eventually consistent reads (speed)
• DynamoDB Streams → Order processing

Epic Games - Player Stats

Scale:
┌──────────────────────────────────────────┐
│ • 350+ million players                   │
│ • Millions concurrent                    │
│ • Real-time leaderboards                 │
│ • Match history and stats                │
└──────────────────────────────────────────┘

DynamoDB Data Model:
┌──────────────────────────────────────────┐
│ Table: PlayerData                        │
│                                          │
│ PK: playerId                             │
│ SK: DATA#{dataType}                      │
│                                          │
│ Examples:                                │
│                                          │
│ 1. Player Profile:                       │
│    PK: player-123                        │
│    SK: DATA#PROFILE                      │
│    {level: 50, xp: 12500, ...}           │
│                                          │
│ 2. Match History:                        │
│    PK: player-123                        │
│    SK: DATA#MATCH#2024-01-15#001         │
│    {kills: 5, placement: 3, ...}         │
│                                          │
│ 3. Inventory:                            │
│    PK: player-123                        │
│    SK: DATA#INVENTORY                    │
│    {skins: [...], weapons: [...]}        │
└──────────────────────────────────────────┘

Table: Leaderboards                        │
│                                          │
│ PK: LEADERBOARD#{season}#{region}        │
│ SK: SCORE#{score}#{playerId}             │
│                                          │
│ Query top 100: Query by PK, DESC on SK   │
└──────────────────────────────────────────┘

Features Used:
• Global Secondary Index for leaderboards
• DynamoDB Streams for analytics
• On-demand capacity for traffic spikes
• Global Tables for multi-region

Samsung SmartThings - Device State

Scale:
┌──────────────────────────────────────────┐
│ • 50+ million connected devices          │
│ • Billions of state updates per day      │
│ • Sub-second response time               │
│ • Device state must be durable           │
└──────────────────────────────────────────┘

DynamoDB Data Model:
┌──────────────────────────────────────────┐
│ Table: DeviceState                       │
│                                          │
│ PK: deviceId                             │
│ SK: timestamp                            │
│                                          │
│ {                                        │
│   "deviceId": "thermostat-456",          │
│   "timestamp": 1673892345,               │
│   "temperature": 72,                     │
│   "humidity": 45,                        │
│   "mode": "auto",                        │
│   "location": "living-room",             │
│   "batteryLevel": 85                     │
│ }                                        │
│                                          │
│ TTL: 30 days (auto-delete old data)      │
└──────────────────────────────────────────┘

Table: DeviceMetadata
┌──────────────────────────────────────────┐
│ PK: deviceId                             │
│                                          │
│ {                                        │
│   "deviceId": "thermostat-456",          │
│   "ownerId": "user-789",                 │
│   "deviceType": "thermostat",            │
│   "firmwareVersion": "2.1.5",            │
│   "registeredAt": 1670000000             │
│ }                                        │
└──────────────────────────────────────────┘

Access Patterns:
• Get latest state: GetItem by deviceId
• Get state history: Query with time range
• Update state: PutItem with timestamp
• GSI on ownerId for user's devices
• DynamoDB Streams → Real-time alerts

Lyft - Ride Matching

Requirements:
┌──────────────────────────────────────────┐
│ • Real-time driver location updates      │
│ • Low latency ride matching              │
│ • High availability (can't miss rides)   │
│ • Scale for millions of rides            │
└──────────────────────────────────────────┘

DynamoDB Data Model:
┌──────────────────────────────────────────┐
│ Table: ActiveRides                       │
│                                          │
│ PK: rideId                               │
│                                          │
│ {                                        │
│   "rideId": "ride-123",                  │
│   "riderId": "rider-456",                │
│   "driverId": "driver-789",              │
│   "status": "IN_PROGRESS",               │
│   "pickupLocation": {                    │
│     "lat": 37.7749,                      │
│     "lon": -122.4194                     │
│   },                                     │
│   "currentLocation": {...},              │
│   "estimatedArrival": 1673892500,        │
│   "fareEstimate": 15.50                  │
│ }                                        │
│                                          │
│ GSI: driverIdIndex                       │
│   PK: driverId                           │
│   SK: status                             │
│   (Find all rides for a driver)          │
└──────────────────────────────────────────┘

Table: DriverLocations
┌──────────────────────────────────────────┐
│ PK: geohash (6-char precision)           │
│ SK: driverId                             │
│                                          │
│ {                                        │
│   "geohash": "9q8yyz",                   │
│   "driverId": "driver-789",              │
│   "location": {lat: 37.7749, ...},       │
│   "status": "AVAILABLE",                 │
│   "rating": 4.9,                         │
│   "lastUpdate": 1673892400               │
│ }                                        │
│                                          │
│ TTL: 5 minutes (stale location cleanup)  │
└──────────────────────────────────────────┘

Features Used:
• Geohashing for location queries
• TTL for automatic cleanup
• GSI for driver queries
• DynamoDB Streams → Analytics/Billing
• Strongly consistent reads for critical ops

When NOT to Use DynamoDB

Anti-Patterns

DynamoDB is NOT suitable for:

┌────────────────────────────────────────────────────────┐
│              DYNAMODB ANTI-PATTERNS                    │
├────────────────────────────────────────────────────────┤
│                                                        │
│  ✗ COMPLEX JOINS ACROSS TABLES                        │
│    ┌────────────────────────────────────────────┐     │
│    │ If your queries need:                      │     │
│    │ • Multi-table joins                        │     │
│    │ • Complex aggregations                     │     │
│    │ • Ad-hoc analytical queries                │     │
│    │                                            │     │
│    │ Use instead: PostgreSQL, Amazon Aurora     │     │
│    └────────────────────────────────────────────┘     │
│                                                        │
│  ✗ UNPREDICTABLE QUERY PATTERNS                       │
│    ┌────────────────────────────────────────────┐     │
│    │ If users need:                             │     │
│    │ • Search across any field                  │     │
│    │ • Full-text search                         │     │
│    │ • Complex filtering on multiple attributes │     │
│    │                                            │     │
│    │ Use instead: Elasticsearch, OpenSearch     │     │
│    └────────────────────────────────────────────┘     │
│                                                        │
│  ✗ ANALYTICS AND REPORTING                            │
│    ┌────────────────────────────────────────────┐     │
│    │ If you need:                               │     │
│    │ • Complex aggregations (SUM, AVG, etc.)    │     │
│    │ • Table scans for reporting                │     │
│    │ • OLAP workloads                           │     │
│    │                                            │     │
│    │ Use instead: Amazon Redshift, Athena       │     │
│    └────────────────────────────────────────────┘     │
│                                                        │
│  ✗ BLOB STORAGE                                       │
│    ┌────────────────────────────────────────────┐     │
│    │ If storing:                                │     │
│    │ • Large files (>400KB per item)            │     │
│    │ • Images, videos                           │     │
│    │ • Binary data                              │     │
│    │                                            │     │
│    │ Use instead: Amazon S3                     │     │
│    │ (Store reference in DynamoDB)              │     │
│    └────────────────────────────────────────────┘     │
│                                                        │
│  ✗ STRONG CONSISTENCY ACROSS REGIONS                  │
│    ┌────────────────────────────────────────────┐     │
│    │ If you need:                               │     │
│    │ • Synchronous multi-region writes          │     │
│    │ • Global strong consistency                │     │
│    │ • Distributed transactions                 │     │
│    │                                            │     │
│    │ Use instead: Amazon Aurora Global,         │     │
│    │              Google Spanner                │     │
│    └────────────────────────────────────────────┘     │
│                                                        │
└────────────────────────────────────────────────────────┘

Deep Dive: The Original Dynamo Paper Concepts in Depth

To truly understand DynamoDB, we need to examine the original Dynamo paper concepts that influenced its design, even though DynamoDB has evolved significantly.

Consistent Hashing Revisited

The original Dynamo paper introduced consistent hashing as a way to distribute data across a ring of nodes:

CONSISTENT HASHING IN ORIGINAL DYNAMO

Ring Space: 0 to 2^128 - 1 (SHA-1 hash range)

Nodes placed on ring by hashing their IP:
- Node A: hash("10.0.1.5:8080") = 1234567890123456789012345678901234567890
- Node B: hash("10.0.1.6:8080") = 2345678901234567890123456789012345678901
- Node C: hash("10.0.1.7:8080") = 3456789012345678901234567890123456789012

Data placement:
- Item with key "user123":
  hash("user123") = 2000000000000000000000000000000000000000
  → Falls between Node A and Node B → Node B is coordinator

Virtual nodes (vnodes):
- Each physical node hosts multiple virtual nodes
- Prevents hotspotting when nodes join/leave
- Provides more uniform distribution
- Used in DynamoDB but abstracted away

Sloppy Quorum and Vector Clocks

The original Dynamo used a sophisticated quorum system:

N: Replication factor (typically 3)
W: Number of nodes that must acknowledge a write before it’s considered successful
R: Number of nodes that must respond to a read request

The relationship between these values determines consistency:

If R + W > N, the system provides strong consistency
If R + W ≤ N, the system provides eventual consistency

Vector clocks were used to track causality between updates:

Each update carries a vector clock: [A:1, B:2, C:1]
Conflicting updates result in “siblings” that must be resolved by the application

Hinted Handoff and Anti-Entropy

Dynamo used “hinted handoff” to handle temporarily unavailable nodes:

If Node A is down, Node B and C will accept writes intended for A
These “hints” are stored and forwarded when A comes back online

Anti-entropy was achieved using Merkle trees:

Nodes periodically compare Merkle tree roots to detect inconsistencies
Only mismatched ranges need to be synchronized, not entire datasets

How DynamoDB Simplified These Concepts

While inspired by these techniques, DynamoDB abstracts them away:

Request Routing Layer: Instead of client-side coordinators, AWS manages request routing
Last-Write-Wins: Instead of vector clocks and application-level conflict resolution, DynamoDB uses timestamps
Managed Operations: Instead of gossip protocols and manual maintenance, AWS handles all operational aspects
Simplified Consistency: Instead of tunable N, R, W, DynamoDB offers only eventual or strongly consistent reads

Evolution of Data Model Concepts

The original Dynamo was a pure key-value store. DynamoDB has expanded this significantly:

From Simple Key-Value to Rich Data Model

Original Dynamo:

Key → Value mapping only
Values treated as opaque blobs
No query capabilities beyond get/put by key

DynamoDB Evolution:

Composite Primary Keys (Partition Key + Sort Key)
Secondary Indexes (GSI and LSI)
Rich attribute types (strings, numbers, binary, sets, lists, maps)
Conditional writes and transactions
Streams for change data capture

Partitioning Strategy Evolution

The consistent hashing concept remains, but with important evolutions:

Virtual Nodes: DynamoDB uses virtual nodes (vnodes) to allow for more granular partitioning and faster rebalancing
Intelligent Splitting: Partitions are split based on capacity consumption, not just node count
Hot Partition Detection: Automatic detection and mitigation of hot partitions
Storage-Compute Separation: Unlike the original Dynamo, compute and storage are separate layers

The Request Routing Evolution

DynamoDB introduced a sophisticated request routing layer:

DYNAMODB REQUEST FLOW

Client → Request Router → Storage Nodes
  ↓         ↓              ↓
  • Parses request      • Stores data
  • Determines route    • Performs operation  
  • Handles retries     • Returns result
  • Throttles if needed
  • Maintains circuit breakers

This routing layer handles:

Partition key hashing to determine correct storage nodes
Load balancing across partitions
Throttling and rate limiting
Circuit breakers for downstream failures
Intelligent retry logic

DynamoDB’s Unique Additions

DynamoDB has introduced several innovations not present in the original Dynamo:

Secondary Indexes (GSI and LSI)

The original Dynamo had no secondary indexes. DynamoDB added:

Local Secondary Indexes (LSI): Alternative sort key for the same partition key
Global Secondary Indexes (GSI): Different partition and sort key combinations

ACID Transactions

DynamoDB introduced multi-item ACID transactions:

Atomic across up to 25 items
All-or-nothing execution
Rollback on failure
Isolation levels

Serverless and Auto-Scaling

On-Demand Capacity: Pay-per-request pricing
Auto-Scaling: Automatic adjustment of provisioned capacity
Adaptive Capacity: Automatic redistribution of capacity across partitions

Advanced Features

DynamoDB Streams: Real-time change data capture
Time-to-Live (TTL): Automatic expiration of items
Global Tables: Multi-region replication with active-active configuration
DynamoDB Accelerator (DAX): In-memory caching for microsecond latency

Architectural Comparison: Dynamo vs DynamoDB

Aspect	Original Dynamo (2007)	DynamoDB (2012+)
Architecture	Peer-to-peer, symmetric nodes	Managed service with request routing
Membership	Gossip protocol	AWS-controlled orchestration
Conflict Resolution	Vector clocks, application-resolved	Last-write-wins, or application-managed
Consistency	Tunable quorums (N,R,W)	Eventual or strongly consistent
Operations	Manual setup, scaling, maintenance	Fully managed, auto-scaling
Client Interface	Direct node communication	AWS SDKs with request routing
Storage Model	Key-value only	Rich data model with indexes
Transactions	None	Multi-item ACID transactions

Key Takeaways

Deep Dynamo Concepts Summary:

Consistent Hashing Foundation: Both systems use consistent hashing for data distribution, though DynamoDB abstracts this away.
Eventual Consistency Origin: The original Dynamo’s focus on availability over consistency directly influenced DynamoDB’s default eventual consistency model.
Operational Evolution: DynamoDB transformed a complex peer-to-peer system into a simple managed service by introducing request routing and abstracting operational complexity.
Feature Addition: DynamoDB significantly expanded on the original Dynamo’s simple key-value model with indexes, transactions, and serverless capabilities.
Abstraction of Complexity: DynamoDB hides the sophisticated distributed systems concepts of the original Dynamo behind a simple API, making them accessible to application developers without requiring deep distributed systems knowledge.

Interview Questions

Question 1: Explain the difference between Amazon's original Dynamo and DynamoDB

Difficulty: MediumWhat they’re testing:

Understanding of distributed systems evolution
Knowledge of trade-offs between P2P and managed services
Ability to explain technical decisions

Strong Answer Structure:

1. ACKNOWLEDGE RELATIONSHIP:
   "DynamoDB is inspired by Amazon's 2007 Dynamo paper
    but significantly different in architecture."

2. CORE ARCHITECTURAL DIFFERENCE:
   "Dynamo: Peer-to-peer, symmetric nodes, client routing
    DynamoDB: Request router layer, managed storage nodes"

3. KEY DIFFERENCES:
   - Conflict resolution: Vector clocks vs LWW
   - Consistency: Tunable (N,R,W) vs 2 levels
   - Operations: Manual vs fully managed
   - Membership: Gossip vs managed control plane

4. WHY THE CHANGES:
   "DynamoDB trades Dynamo's flexibility for:
    - Operational simplicity
    - Predictable performance
    - Multi-tenancy support
    - Lower barrier to entry"

5. RESULT:
   "DynamoDB is easier to use and operate, while
    Dynamo gives more control (like Cassandra)"

Follow-up: Why did Amazon create DynamoDB when Dynamo already worked internally?Answer: Operational burden. Teams needed distributed KV storage but couldn’t afford the complexity of running Dynamo. A managed service democratized access to this capability.

Question 2: Why does DynamoDB choose availability over strong consistency?

Difficulty: Easy-MediumWhat they’re testing:

Understanding of CAP theorem
Knowledge of business requirements
Ability to explain trade-offs

Strong Answer:

1. CAP THEOREM CONSTRAINT:
   "In distributed systems, you can have at most
    2 of: Consistency, Availability, Partition Tolerance.
    Since network partitions WILL happen, you must
    choose between C and A."

2. AMAZON'S BUSINESS REQUIREMENT:
   "For Amazon.com, availability is critical.
    A customer seeing an error page loses sales.
    A customer seeing a slightly stale shopping cart
    is acceptable and fixable."

3. THE TRADE-OFF:
   Strong Consistency (RDBMS):
   - Partition occurs → Can't write → Downtime
   - 100% consistent but unavailable

   Eventual Consistency (DynamoDB):
   - Partition occurs → Both sides write → Available
   - Temporarily inconsistent but always accepting writes
   - Conflicts resolved later

4. REAL-WORLD IMPACT:
   "It's better to show duplicate items in a cart
    (can be deduplicated at checkout) than to prevent
    adding items altogether."

5. NUANCE:
   "DynamoDB offers BOTH eventual and strong consistent
    reads, letting you choose per-operation. But writes
    are always available."

Common Mistake: Saying DynamoDB is “eventually consistent” without mentioning it offers strong consistent reads as an option.

Question 3: What is the shopping cart problem and how did it lead to Dynamo?

Difficulty: EasyWhat they’re testing:

Understanding of real-world requirements
Knowledge of system design motivation
Ability to connect business needs to technical solutions

Strong Answer:

THE PROBLEM:
┌────────────────────────────────────────┐
│ Amazon.com Peak Shopping (2004-2005):  │
│                                        │
│ • Millions of concurrent users         │
│ • Shopping cart must NEVER be down     │
│ • Lost cart = Lost revenue             │
│ • Database outages unacceptable        │
└────────────────────────────────────────┘

TRADITIONAL DATABASE FAILURE:
┌────────────────────────────────────────┐
│ Master-Slave RDBMS:                    │
│                                        │
│ Network partition occurs               │
│ → Slave can't sync with master         │
│ → DENY WRITES (to maintain consistency)│
│ → Customer sees error                  │
│ → LOST SALE                            │
└────────────────────────────────────────┘

THE INSIGHT:
"It's better to allow a customer to add an item
 to their cart (even if it creates a conflict)
 than to show an error page. We can merge
 duplicate items later at checkout."

THE SOLUTION (Dynamo):
┌────────────────────────────────────────┐
│ • Always accept writes (high availability)
│ • Store on multiple nodes              │
│ • Resolve conflicts later              │
│ • Shopping cart: Union of all versions │
│ • Customer never sees downtime         │
└────────────────────────────────────────┘

RESULT:
This requirement drove the creation of Dynamo,
an AP (Available, Partition-tolerant) system.

Question 4: Compare DynamoDB with Apache Cassandra

Difficulty: Medium-HardWhat they’re testing:

Deep understanding of both systems
Knowledge of Dynamo-inspired databases
Ability to compare trade-offs

Strong Answer:

SIMILARITIES (Both from Dynamo paper):
┌────────────────────────────────────────┐
│ • Consistent hashing partitioning      │
│ • Eventual consistency model           │
│ • High availability focus              │
│ • Horizontal scalability               │
│ • Tunable consistency (Cassandra)      │
└────────────────────────────────────────┘

KEY DIFFERENCES:

1. OPERATIONS:
   Cassandra: Self-managed (you run cluster)
   DynamoDB: Fully managed by AWS

2. ARCHITECTURE:
   Cassandra: True P2P (like original Dynamo)
   DynamoDB: Request router + storage nodes

3. CONSISTENCY:
   Cassandra: Tunable per query (ONE, QUORUM, ALL)
   DynamoDB: Two levels (eventual vs strong)

4. DATA MODEL:
   Cassandra: Wide-column store with CQL
   DynamoDB: Key-value with item collections

5. QUERY LANGUAGE:
   Cassandra: CQL (SQL-like)
   DynamoDB: API-based (GetItem, Query, Scan)

6. PRICING:
   Cassandra: Infrastructure costs (EC2, storage)
   DynamoDB: Pay-per-request or provisioned capacity

7. SCALABILITY:
   Cassandra: Manual node addition, rebalancing
   DynamoDB: Automatic, transparent scaling

8. CONFLICT RESOLUTION:
   Cassandra: Last-write-wins or timestamps
   DynamoDB: Last-write-wins

WHEN TO CHOOSE EACH:

Choose DynamoDB when:
• You want zero operational burden
• You need AWS integration
• You want automatic scaling
• You're okay with AWS vendor lock-in

Choose Cassandra when:
• You need multi-cloud or on-prem
• You want fine-grained control
• You have ops expertise
• You need CQL query flexibility

Question 5: Design a data model for a use case in DynamoDB

Difficulty: HardScenario: Design a DynamoDB schema for Twitter-like functionality supporting:

Post tweets
Follow/unfollow users
View user timeline (tweets from followed users)
View user’s own tweets

What they’re testing:

Understanding of DynamoDB data modeling
Knowledge of access patterns-first design
Ability to use composite keys and GSI

Strong Answer:

STEP 1: IDENTIFY ACCESS PATTERNS
┌────────────────────────────────────────┐
│ 1. Get user profile                    │
│ 2. Post a tweet                        │
│ 3. Get user's tweets                   │
│ 4. Get timeline (followed users' tweets)│
│ 5. Follow/unfollow user                │
│ 6. Get user's followers                │
│ 7. Get who user follows                │
└────────────────────────────────────────┘

STEP 2: DESIGN SINGLE TABLE
┌────────────────────────────────────────┐
│ Table: SocialMedia                     │
│                                        │
│ PK (Partition Key)                     │
│ SK (Sort Key)                          │
└────────────────────────────────────────┘

STEP 3: ENTITY PATTERNS

User Profile:
PK: USER#alice
SK: #METADATA
{username: "alice", bio: "...", created: ...}

User's Tweet:
PK: USER#alice
SK: TWEET#2024-01-15T10:30:00#tweet123
{tweetId: "tweet123", content: "...", likes: 0}

Following Relationship:
PK: USER#alice
SK: FOLLOWS#USER#bob
{followedAt: 1673892000}

Follower Relationship:
PK: USER#bob
SK: FOLLOWED_BY#USER#alice
{followedAt: 1673892000}

Timeline (Fan-out on write):
PK: USER#alice#TIMELINE
SK: TWEET#2024-01-15T10:30:00#tweet123
{authorId: "bob", content: "...", ...}

STEP 4: ACCESS PATTERN QUERIES

1. Get user profile:
   GetItem(PK=USER#alice, SK=#METADATA)

2. Post tweet:
   PutItem(PK=USER#alice, SK=TWEET#{timestamp}#{id})
   + Fan out to all followers' timelines

3. Get user's tweets:
   Query(PK=USER#alice, SK begins_with "TWEET#")

4. Get timeline:
   Query(PK=USER#alice#TIMELINE, SK begins_with "TWEET#")
   Limit=20, ScanIndexForward=false (descending)

5. Follow user:
   PutItem(PK=USER#alice, SK=FOLLOWS#USER#bob)
   PutItem(PK=USER#bob, SK=FOLLOWED_BY#USER#alice)

6. Get followers:
   Query(PK=USER#bob, SK begins_with "FOLLOWED_BY#")

STEP 5: CONSIDERATIONS

Pros:
• All related data in same partition (hot user data)
• Fast timeline reads (no joins needed)
• Single-digit ms latency

Cons:
• Fan-out writes expensive (celeb with 10M followers)
• Need to handle fan-out asynchronously
• Potential hot partitions for celebrities

Optimization for Celebrities:
• Don't fan out tweets from users with >10k followers
• Instead, use pull model (read from multiple users)
• Or hybrid: Fan out to active followers only

Follow-up: How would you handle a celebrity with 10 million followers?Answer: Switch to pull-based timeline for celebrities. When user loads timeline, query the users they follow in parallel (scatter-gather). Use GSI or separate fan table. Cache results in DAX/ElastiCache.

What’s Next?

In Chapter 2: Architecture and Partitioning, we’ll dive deep into:

DynamoDB’s system architecture
Consistent hashing and how partitioning works
Request routing and the storage node design
Auto-scaling and adaptive capacity

Continue to Chapter 2

Explore DynamoDB’s architecture, consistent hashing, and partitioning strategy

Additional Resources

Original Dynamo Paper: “Dynamo: Amazon’s Highly Available Key-value Store” (SOSP 2007)
DynamoDB Announcement: AWS re:Invent 2012 keynote
CAP Theorem: “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services” (2002)
AWS Architecture Blog: DynamoDB design patterns and best practices

​Chapter 1: Introduction and Origins

​The Origins: Amazon’s Availability Challenge

​The Shopping Cart Problem (2004-2005)

​The CAP Theorem Dilemma

​The Dynamo Paper (2007)

​Paper Overview

​Dynamo Design Principles

​Dynamo Architecture Overview

​From Dynamo to DynamoDB

​The Evolution (2007-2012)

​Key Differences: Dynamo vs DynamoDB

​Why DynamoDB Changed Design

​DynamoDB Design Goals

​Primary Requirements

​Non-Goals (What DynamoDB is NOT)

​Target Workloads and Use Cases

​Ideal Workloads for DynamoDB

​Real-World Examples

​When NOT to Use DynamoDB

​Anti-Patterns

​Deep Dive: The Original Dynamo Paper Concepts in Depth

​Consistent Hashing Revisited

​Sloppy Quorum and Vector Clocks

​Hinted Handoff and Anti-Entropy

​How DynamoDB Simplified These Concepts

​Evolution of Data Model Concepts

​From Simple Key-Value to Rich Data Model

​Partitioning Strategy Evolution

​The Request Routing Evolution

​DynamoDB’s Unique Additions

​Secondary Indexes (GSI and LSI)

​ACID Transactions

​Serverless and Auto-Scaling

​Advanced Features

​Architectural Comparison: Dynamo vs DynamoDB

​Key Takeaways

​Interview Questions

​What’s Next?

Continue to Chapter 2

​Additional Resources

Chapter 1: Introduction and Origins

The Origins: Amazon’s Availability Challenge

The Shopping Cart Problem (2004-2005)

The CAP Theorem Dilemma

The Dynamo Paper (2007)

Paper Overview

Dynamo Design Principles

Dynamo Architecture Overview

From Dynamo to DynamoDB

The Evolution (2007-2012)

Key Differences: Dynamo vs DynamoDB

Why DynamoDB Changed Design

DynamoDB Design Goals

Primary Requirements

Non-Goals (What DynamoDB is NOT)

Target Workloads and Use Cases

Ideal Workloads for DynamoDB

Real-World Examples

When NOT to Use DynamoDB

Anti-Patterns

Deep Dive: The Original Dynamo Paper Concepts in Depth

Consistent Hashing Revisited

Sloppy Quorum and Vector Clocks

Hinted Handoff and Anti-Entropy

How DynamoDB Simplified These Concepts

Evolution of Data Model Concepts

From Simple Key-Value to Rich Data Model

Partitioning Strategy Evolution

The Request Routing Evolution

DynamoDB’s Unique Additions

Secondary Indexes (GSI and LSI)

ACID Transactions

Serverless and Auto-Scaling

Advanced Features

Architectural Comparison: Dynamo vs DynamoDB

Key Takeaways

Interview Questions

What’s Next?

Additional Resources