INTRODUCTION👋

Why should you care about DynamoDB? Because it's fully managed, highly scalable & scales on-demand with low latencies.

For getting you hooked, at Prime Days 2021 DynamoDB served 89.2 million requests per second at its peak!

CAPACITY MODES📦

You can choose between those two types, which can be changed any time:

• provisioned - specifying the capacity units for your table & you'll be independently charged from your actual usage
• on-demand - you'll be charged per request.

The best fit highly depends on your traffic patterns.

ON-DEMAND VS. PROVISIONED🔄

Go with On-Demand if you got unpredictable traffic, as it scales immediately and you're only paying for what you actually use.

With steady load or known patterns, use provisioned as it can be up to almost 7 times less expensive.

Rule of thumb:

• variable, unpredictable traffic → on-demand
• variable, predictable traffic → provisioned
• steady, predictable traffic → provisioned

FREE TIER💰

Your first year includes 25 Read & Write Capacity Units each for provisioned capacity mode every month.

BASIC CONCEPTS📝

In comparison to SQL, a document in DynamoDB doesn't have a fixed schema but is defined by the table, the primary key, which uniquely identifies a single document.

PRIMARY KEYS🔑

It's is a document's unique identifier & must be provided when inserting a new item.

There are two different types of primary keys:

• simple - your partition key & therefore a single field.
• composite - a combination of your partition & sort key.

PARTITION KEYS🔀

Internally, DynamoDB consists of different partitions and your partition key will determine the partition where an item will be stored at.

HOT PARTITIONS🔥

Your provisioned read & write capacity units will be distributed among all partitions.

If your partition keys are not well-distributed, it will be easier to get your requests throttled as a subset of your partitions (or worse: a single) can receive the majority of read and/or write requests.

DynamoDB will increase capacity for hot partitions as long as the table-level throughput is not exceeded Adaptive Capacity.

But more concernness: If there's disproportionally high traffic to one or several items in the same partition, DynamoDB will isolance partitions such that those items don't reside on the same partition.

SORT KEYS🔽

Using sort keys comes with benefits:

• they can be used with operators in queries such as begins_with, between, >, < and so on.
• you can create hierarchical (1:n) relationships - citing an example from the docs: [country].[region].[state].[county].[city]
• The combination of a partition & sort key (= your primary key) needs to be unique.

Keys should be well distributed to avoid hot partitions.

SECONDARY INDEXES📑

You can create two types of indexes, which are specifying alternative keys that can be used for queries:

• Local Secondary Index (LSI) - needs to have the same partition key, but an alternative sort key.
• Global Secondary Index (GSI) - partition & sort key can be different.

DATA TYPES🔢

Besides your primary key, your document can contain other data in different Scalar, Document and Set.

SCALAR:

• String (S)
• Number (N)
• Binary (B)
• Boolean (BOOL)
• Null (NULL)

DOCUMENT:

• Complex structure with nested attributes
• List (L)
• Map (M)

SET:

• Multiple unique values
• String Set (SS)
• Number Set (NS)
• Binary Set (BS)

RETRIEVING ITEMS🔍

That's where it gets interesting and makes differences to SQL or other NoSQL solutions.

You can only query via your partition key (and sort key) condition, if there's any) of your main or secondary indexes.

Everything else needs scan.

QUERY🔎

With query, you're only paying for the retrieved items. It's only looking for the items at a specific partition. So generally speaking: query is way faster and cheaper.

SCAN🔍

A scan is just running through your table looking for items that are matching your expression.

You'll be charged for the items that are scanned, not the items that are retrieved.

RACE CONDITIONS⚡

Often, there are possible race conditions due to multi-tenancy where writes can be lost.

Example:

• Lambda A reads Document X
• Lambda B reads Document X
• Lambda A writes Document X
• Lambda B writes Document X

OPTIMISTIC LOCKING🔒

DynamoDB's Optimistic Locking allows us to verify that we're really updating the item we're expecting by using a dedicated version field.

In the previous example, both read operations would read version 1 and also expect to write version 2. The first operation would succeed, but the second would fail as the expected version would not match with the expectations.

STREAMS🔄

Asynchronously trigger invocations of other services like Lambda when an item is created, updated or deleted.

BACKUPS🔐

AWS offers you a lot of options for backing up your tables.

• On-Demand Backups - trigger backups manually or via a scheduled event.
• Continuous Backups via Point-In-Time-Recovery (PITR) - enables you to restore your table to any state with the last 35 days.
• Exporting Backups to S3 - export your data to an S3 bucket. You can also automate/trigger this process via Lambda & EventBridge rules.

UPDATE EXPRESSIONS🔄

Safely modify one or multiple fields of a complex document:

• SET - adding one or several attributes to an item.
• REMOVE - removing one or several attributes.
• ADD - adding new attributes with its value.
• DELETE - remove one or more elements from a set.

GLOBAL TABLES🌐

Distribute your data globally across tables for redundancy and faster latencies.

A bi-directional synchronization will replicate your data between different regions.

OBSERVABILITY👁️

CloudWatch comes with default metrics like used read & write capacity units or the number of throttles. Helps to analyse DynamoDB traffic patterns so you can optimise for low costs.

Third-party tools like Dashbird.io help you with Slack notifications for critical events like throttles & give you general guidance with well-architected tips.