DynamoDB

• Fully-Managed - This means that AWS takes care of all the operational aspects of the database. The fully-managed nature allows AWS to handle all operational tasks — hardware provisioning, configuration, patching, and scaling — freeing developers to concentrate on application development.
• Highly Scalable - DynamoDB can handle massive amounts of data and traffic. It automatically scales up or down to adjust to your application's needs, without any downtime or performance degradation.
• Key-value - DynamoDB is a NoSQL database, which means it doesn't use the traditional relational database model. Instead, it uses a key-value model that allows for flexible data storage and retrieval.

The Data Model

{
  "PersonID": 101,
  "LastName": "Smith",
  "FirstName": "Fred",
  "Phone": "555-4321"
},
{
  "PersonID": 102,
  "LastName": "Jones",
  "FirstName": "Mary",
  "Address": {
    "Street": "123 Main",
    "City": "Anytown",
    "State": "OH",
    "ZIPCode": 12345
  }
},
{
  "PersonID": 103,
  "LastName": "Stephens",
  "FirstName": "Howard",
  "Address": {
    "Street": "123 Main",
    "City": "London",
    "PostalCode": "ER3 5K8"
  },
  "FavoriteColor": "Blue"
}

Partition Key and Sort Key

1. Partition Key - A single attribute that, along with the sort key (if present), uniquely identifies each item in the table. DynamoDB uses the partition key's value to determine the physical location of the item within the database. This value is hashed to determine the partition where the item is stored.
2. Sort Key (Optional) - An additional attribute that, when combined with the partition key, forms a composite primary key. The sort key is used to order items with the same partition key value, enabling efficient range queries and sorting within a partition.

Secondary Indexes

1. Global Secondary Index (GSI) - An index with a partition key and optional sort key that differs from the table's partition key. GSIs allow you to query items based on attributes other than the table's partition key. Since GSIs use a different partition key, the data is stored on entirely different physical partitions from the base table and is replicated separately.
2. Local Secondary Index (LSI) - An index with the same partition key as the table's primary key but a different sort key. LSIs enable range queries and sorting within a partition. Since LSIs use the same partition key as the base table, they are stored on the same physical partitions as the items they're indexing.

1. Global Secondary Indexes (GSIs):

   • Each GSI is essentially a separate table with its own partition scheme.
   • When an item is added, updated, or deleted in the main table, DynamoDB asynchronously updates the GSI.
   • GSIs use the same hash partitioning mechanism as the main table, but with different partition and sort keys.
   • This allows for efficient querying on non-primary key attributes across all partitions.
2. Local Secondary Indexes (LSIs):

   • LSIs are co-located with the main table's partitions, sharing the same partition key.
   • They maintain a separate B-tree structure within each partition, indexed on the LSI's sort key.
   • Updates to LSIs are done synchronously with the main table updates. LSI reads support both eventually consistent (default) and strongly consistent reads, just like the base table.
3. Index Maintenance:

   • DynamoDB automatically propagates changes from the main table to all secondary indexes.
   • For GSIs, this propagation is asynchronous (eventually consistent). For LSIs, updates happen synchronously with the base table write.
   • The system manages the additional write capacity required for index updates.
4. Query Processing:

   • When a query uses a secondary index, DynamoDB routes the query to the appropriate index table (for GSIs) or index structure (for LSIs).
   • It then uses the index's partition and sort key mechanics to efficiently retrieve the requested data.

Accessing Data

SELECT * FROM users WHERE user_id = 101

const params = {
  TableName: 'users',
  KeyConditionExpression: 'user_id = :id',
  ExpressionAttributeValues: {
    ':id': 101
  }
};

dynamodb.query(params, (err, data) => {
  if (err) console.error(err);
  else console.log(data);
});

SELECT * FROM users

const params = {
  TableName: 'users'
};

dynamodb.scan(params, (err, data) => {
  if (err) console.error(err);
  else console.log(data);
});

CAP Theorem

• Reads can be served by any of the three replicas in the partition's replication group
• Since the leader replicates writes to followers asynchronously (after quorum acknowledgment), a follower might not have the very latest write yet
• Consumes less read capacity (0.5 RCU per 4KB) and provides lower latency

• The read request is routed directly to the leader node for the partition
• Since all writes go through the leader first, it always has the most current data
• Consumes more read capacity (1 RCU per 4KB) and may have higher latency
• Not supported on Global Secondary Indexes (GSIs)

Architecture and Scalability

Scalability

Fault Tolerance and Availability

Security

Pricing Model

Advanced Features

DAX (DynamoDB Accelerator)

Streams

DynamoDB in an Interview

When to use It

Knowing its limitations

1. Cost Efficiency: DynamoDB's pricing model is based on read and write operations plus stored data, which can get expensive with high-volume workloads. If you need hundreds of thousands of writes per second, the cost might outweigh the benefits.
2. Complex Query Patterns: If your system requires complex queries, such as those needing joins or ad-hoc aggregations, DynamoDB might not cut it. DynamoDB does support transactions across multiple tables (up to 100 items per transaction), but it lacks the flexible querying capabilities of SQL databases.
3. Data Modeling Constraints: DynamoDB demands careful data modeling to perform well, optimized for key-value and document structures. If you find yourself frequently using Global Secondary Indexes (GSIs) and Local Secondary Indexes (LSIs), a relational database like PostgreSQL might be a better fit.
4. Vendor Lock-in: Choosing DynamoDB means locking into AWS. Many interviewers will want you to stay vendor-neutral, so you may need to consider open-source alternatives to avoid being tied down.

Summary