# DynamoDB Streams

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/dynamodb-streams

## Quick definition

DynamoDB Streams records every change made to a DynamoDB table and lets you view or act on those changes. You can use it to sync data, trigger notifications, or analyze updates. It works in near real time without slowing down your main database. The stream data is stored for 24 hours by default.

## Simple meaning

Imagine you are running a library where people borrow and return books. Each time a book is checked out or returned, you write it down in a logbook. DynamoDB Streams is like that logbook for your database. Whenever someone adds a new record, changes an existing record, or deletes a record, DynamoDB Streams automatically writes down what happened, when, and what the old and new values were. You can then have a separate program read this logbook and do something useful with the information. For example, if a customer changes their shipping address, a stream event can trigger an email confirmation to be sent. Or if a product inventory count drops to zero, a stream event can notify a warehouse system to restock. The streams are not the same as the table itself. They are a separate, temporary log that keeps changes for up to 24 hours. This allows other services to process the data without slowing down the main database operations. Think of it as a dedicated change journal that can feed into other applications, analytics pipelines, or backup systems. The stream does not store the entire table data, only the changes. This makes it efficient for building event-driven architectures where action is taken based on specific data modifications. You can also control how much information each stream event contains, such as whether to include the old image, the new image, or both. This flexibility helps you balance between cost and the level of detail you need for your downstream processing. In everyday terms, DynamoDB Streams is the silent observer that takes notes on every edit, and then hands those notes to any service that needs to stay updated. It is a fundamental building block for modern applications that need to react to database changes in real time.

## Technical definition

DynamoDB Streams is an optional, fully managed feature of Amazon DynamoDB that captures a time-ordered sequence of item-level modifications in a DynamoDB table. When enabled on a table, DynamoDB automatically writes a stream record every time a Create, Update, or Delete operation is performed on an item. These stream records are durably stored in a log for up to 24 hours and can be accessed via the DynamoDB Streams API or integrated with AWS Lambda, Amazon Kinesis, or other consumers. The stream records are organized into shards. Each shard contains a sequence of records that represents changes to a subset of items in the table. DynamoDB Streams uses the same partitioning scheme as the underlying table, so the number of shards can scale with the table's throughput. Each stream record is a JSON document that includes the event type (INSERT, MODIFY, REMOVE), the keys of the changed item, the approximate timestamp, and optionally the old and new images of the item. The level of detail is controlled by the StreamViewType parameter, which can be set to KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES, or (for DynamoDB Streams only) KEYS_ONLY. DynamoDB Streams is integrated with AWS Lambda via DynamoDB event source mappings, which poll the stream and invoke a Lambda function synchronously with a batch of records. The stream ensures at-least-once delivery but does not guarantee exactly-once processing, so consumer applications must be idempotent. The maximum retention period for a stream record is 24 hours; after that, the record is automatically deleted. DynamoDB Streams has no additional cost for the first 2.5 million read request units per month, after which standard pricing applies. DynamoDB Streams is different from Kinesis Data Streams; DynamoDB Streams is purpose-built for table change capture, while Kinesis is a general-purpose streaming platform. In real IT implementations, DynamoDB Streams is used for cross-region replication (via DynamoDB Global Tables), change data capture (CDC) for data lakes, real-time aggregation pipelines, cache invalidation, and event-driven microservices architectures. For the AWS Certified Developer – Associate exam, understanding the differences between StreamViewType options, the integration with Lambda, and the implications of unordered stream processing across shards is critical.

## Real-life example

Think about a busy coffee shop that keeps track of its inventory on a whiteboard. Every time a customer orders a latte, a barista crosses out the old latte count and writes the new number. This whiteboard is like your DynamoDB table. Now imagine that the coffee shop also has a separate notebook where a manager writes down every single change: who changed the board, what the old number was, what the new number is, and exactly when it happened. That notebook is the DynamoDB Streams. Later in the day, the accountant reads the notebook to update the ordering system. If the latte count dropped below ten, the notebook entry triggers an automatic message to the supplier to send more milk. In this analogy, the notebook is not the whiteboard; it is a separate log that records each change. The accountant does not need to stand at the whiteboard all day, because the notebook already has everything needed. This is exactly how DynamoDB Streams works. The stream captures every insert, update, or delete event without affecting the performance of the main table. It is the silent scribe that makes sure no change goes unnoticed. In a real application, that notebook (the stream) can feed into a Lambda function that sends a welcome email when a new user signs up, or into a Kinesis stream that aggregates website click data. The coffee shop manager can also choose how detailed the notebook entries should be. They could opt to write down just the item that changed (KEYS_ONLY), the new value (NEW_IMAGE), the old value (OLD_IMAGE), or both. This flexibility ensures that the downstream process gets exactly the information it needs, nothing more and nothing less. The notebook eventually gets recycled every 24 hours, so if the accountant does not read it in time, the information is lost. This is why applications that consume DynamoDB Streams must be designed to read and process the records within the retention window.

## Why it matters

DynamoDB Streams matters because it enables real-time event-driven architectures without requiring you to manage any additional infrastructure. In a typical IT environment, databases are often isolated components that only communicate through direct queries. DynamoDB Streams breaks this isolation by turning every data change into an event that can be consumed by other services. This is crucial for building responsive applications. For example, an e-commerce platform needs to update its search index immediately after a product price changes. Without DynamoDB Streams, you would need to write custom logic in your application to update the search index every time a product is modified, which is error-prone and increases latency. With DynamoDB Streams, the database itself emits the change, and a separate process (like a Lambda function) updates the search index automatically. This decoupling makes the system more scalable and maintainable. Another practical use is cross-region replication using DynamoDB Global Tables. DynamoDB Global Tables uses streams to asynchronously replicate changes from one region to another, ensuring low-latency reads everywhere. Without streams, you would need to build a complex replication mechanism yourself. DynamoDB Streams also simplifies change data capture (CDC) for analytics. Many organizations want to stream database changes into Amazon S3, Redshift, or OpenSearch for real-time analytics. DynamoDB Streams can feed into Kinesis Data Streams, which then flows into these destinations. This pattern is used in financial services for fraud detection, in gaming for live leaderboards, and in IoT for device state monitoring. DynamoDB Streams is essential for maintaining data consistency across microservices. When a user profile is updated in a DynamoDB table, a stream event can trigger a Lambda function that sends a notification to other services, such as an email service or a cache cleaner. This ensures that all parts of the system stay synchronized without tight coupling. For IT professionals, understanding DynamoDB Streams means you can design systems that react to data changes instantly, improving user experience and operational efficiency. It also reduces the need for polling, which wastes resources and introduces latency.

## Why it matters in exams

DynamoDB Streams is a core topic for the AWS Certified Developer – Associate (DVA-C02) exam. The exam objectives explicitly include designing event-driven architectures and using DynamoDB Streams to trigger Lambda functions. Questions often test your understanding of how to enable streams, configure StreamViewType, and integrate with Lambda via event source mappings. You will also encounter scenario-based questions where you need to decide whether to use DynamoDB Streams or Kinesis Data Streams for a given use case. The exam may ask you to choose the correct StreamViewType to minimize cost while still providing the necessary data for a downstream process. For example, if you only need the primary key of the modified item for cache invalidation, you should select KEYS_ONLY. If you need the new values for analytics, you would choose NEW_IMAGE. Another common exam scenario involves ordering guarantees. DynamoDB Streams guarantees ordering within a single shard, but not across shards. This means if your application requires strict global ordering of changes, you may need to use a single shard or implement additional logic. The exam will test whether you understand this limitation. Lambda event source mappings for DynamoDB Streams must have the correct IAM permissions, including dynamodb:DescribeStream, dynamodb:GetRecords, dynamodb:GetShardIterator, and dynamodb:ListStreams. You also need to configure the batch size (how many records are sent per invocation) and the starting position (LATEST or TRIM_HORIZON). Questions may ask you to troubleshoot why a Lambda function is not being triggered, which often points to misconfigured IAM roles or incorrect event source mapping settings. The exam covers the integration of DynamoDB Streams with DynamoDB Global Tables. You should understand that Global Tables uses DynamoDB Streams to replicate data across regions, and that the replication is asynchronous. This is important for disaster recovery and multi-region active-active architectures. Finally, you may see questions about stream record structure. Knowing that stream records contain the event ID, event type, approximate creation time, and optionally the old and new images will help you interpret exam scenarios. The exam will not ask you to memorize exact JSON formats, but you should understand what each component represents.

## How it appears in exam questions

DynamoDB Streams appears in exam questions in several common patterns. The first is the scenario-based pattern. You are given a description of an application that needs to react to database changes. For example, "A photo sharing application uses DynamoDB to store user metadata. When a user updates their profile picture URL, a thumbnail generation service must be triggered. What is the most efficient way to achieve this?" The correct answer is to enable DynamoDB Streams on the table and configure a Lambda function to process the stream events and invoke the thumbnail service. Distractors may include using an Amazon SNS topic for each update (which adds overhead) or having the application poll the database every few seconds. The second pattern is the configuration question. You might be asked: "A developer has enabled DynamoDB Streams with StreamViewType set to NEW_IMAGE. The Lambda function only needs the keys of the item to update a search index. What change should the developer make?" The correct answer is to change StreamViewType to KEYS_ONLY to reduce cost and data size. The third pattern is the troubleshooting question. For instance: "A Lambda function is subscribed to a DynamoDB Stream, but it is not receiving any events. Streams are enabled on the table. What is the most likely cause?" Answer options could include: the Lambda function's IAM role lacks the dynamodb:GetRecords permission, the event source mapping is in a disabled state, or the Lambda function's timeout is too short. You need to know that IAM permissions for the Lambda execution role are a common misconfiguration. The fourth pattern is the ordering and shard question. Example: "An application processes DynamoDB Stream records and must maintain the order of changes for each item. Which statement about DynamoDB Streams is correct?" The correct answer is that records are ordered within a shard, but not across shards. The question may ask you to design a solution that guarantees ordering, in which case you would ensure that all items with the same partition key end up in the same shard. The fifth pattern is the comparison with other services. You might be asked: "Why would a developer choose DynamoDB Streams over Kinesis Data Streams for capturing DynamoDB table changes?" The answer focuses on ease of setup, native integration, and lower operational overhead. Finally, the exam may present a multi-service architecture diagram and ask you to identify the component responsible for change capture. Always look for DynamoDB Streams as the arrow from DynamoDB to Lambda or Kinesis.

## Example scenario

Consider an online bookstore that uses DynamoDB to store its inventory. Each book has an item in the table with attributes like ISBN, title, author, quantity, and price. The bookstore wants to automatically send a low-stock alert to the warehouse manager when the quantity of any book drops below five. Whenever the price of a book is updated, the website must refresh its product page cache to show the new price immediately. The manual approach would be to write code in the checkout service that checks the stock after every sale and sends an alert, and to have the admin panel trigger a cache refresh when a price is updated. This is messy and error-prone, as it mixes business logic with the checkout and admin code. Instead, the developer enables DynamoDB Streams on the inventory table with StreamViewType set to NEW_AND_OLD_IMAGES. This means every stream record will contain both the previous and the new values of the item. The developer then creates an AWS Lambda function that processes the stream records. The Lambda function is configured using an event source mapping that polls the stream. When a stream record arrives with event type MODIFY and the new quantity is less than five, the Lambda function sends an email alert to the warehouse manager using Amazon SES. When a MODIFY event shows that the price attribute has changed, the Lambda function calls the website's API to invalidate the cache for that product. Because the stream provides both old and new images, the Lambda function can compare them to determine exactly what changed. This scenario shows how DynamoDB Streams decouples the business logic from the main application, making the system more modular and scalable. If the warehouse later wants to also track which books are being removed from the table, the same Lambda function can handle DELETE events as well. The developer does not need to change anything in the bookstore's main code. This is the power of event-driven architecture with DynamoDB Streams.

## Common mistakes

- **Mistake:** Thinking DynamoDB Streams stores data for more than 24 hours.
  - Why it is wrong: DynamoDB Streams has a maximum retention period of 24 hours. After that, stream records are automatically deleted. It is not a long-term storage solution.
  - Fix: If you need to keep change history beyond 24 hours, use the stream to archive records to Amazon S3 or another persistent store.
- **Mistake:** Believing DynamoDB Streams records are delivered in exact order across all shards.
  - Why it is wrong: Order is guaranteed only within a single shard. Records from different shards may be processed in an interleaved manner.
  - Fix: If global ordering is critical, design your partition keys so that all related items are in the same shard, or use a single shard (which may limit throughput).
- **Mistake:** Assuming enabling DynamoDB Streams automatically integrates with Lambda without any additional configuration.
  - Why it is wrong: You must explicitly create an event source mapping between the Lambda function and the DynamoDB Stream. The Lambda function also needs proper IAM permissions.
  - Fix: After enabling the stream, create the event source mapping using the AWS CLI, SDK, or console, and attach an IAM role that includes dynamodb:GetRecords, dynamodb:DescribeStream, dynamodb:GetShardIterator, and dynamodb:ListStreams.
- **Mistake:** Choosing NEW_AND_OLD_IMAGES for every use case without considering cost.
  - Why it is wrong: Including both images in every stream record increases the size of the data, which leads to higher read request unit consumption and cost.
  - Fix: Select the StreamViewType that matches your actual need. If you only need the new values, use NEW_IMAGE. If only the keys, use KEYS_ONLY.
- **Mistake:** Thinking that DynamoDB Streams can be used with DynamoDB Accelerator (DAX).
  - Why it is wrong: DAX is an in-memory cache for DynamoDB. Changes made through DAX are not immediately reflected in the stream. Streams work at the DynamoDB table level, not the cache level.
  - Fix: Write directly to the DynamoDB table if you need stream events. DAX is for read-heavy workloads, and stream integration should target the underlying table.

## Exam trap

{"trap":"A question states that a DynamoDB table has streams enabled, and a Lambda function is connected. When the table is updated, the Lambda function does not trigger. The answer option suggests that the Lambda function's reserved concurrency is set to zero.","why_learners_choose_it":"Learners know that reserved concurrency can prevent Lambda invocations, so they assume if it is zero, no invocations happen. They may not look at the IAM permissions or event source mapping first.","how_to_avoid_it":"Remember that the most common cause for a Lambda function not being triggered by DynamoDB Streams is a missing or incorrect IAM role that does not grant the necessary DynamoDB Streams permissions. Reserved concurrency being zero would prevent all invocations, but that is a less common scenario. Always check IAM permissions and the event source mapping status first."}

## Commonly confused with

- **DynamoDB Streams vs Amazon Kinesis Data Streams:** Kinesis Data Streams is a general-purpose streaming platform that can ingest data from many sources, not just DynamoDB. DynamoDB Streams is purpose-built for capturing DynamoDB table changes. DynamoDB Streams has a 24-hour retention, while Kinesis can retain data up to 365 days. DynamoDB Streams also has automatic scaling tied to the table's throughput, whereas Kinesis requires manual shard management. (Example: For capturing all changes from a DynamoDB table, use DynamoDB Streams. For aggregating web server logs from multiple sources, use Kinesis Data Streams.)
- **DynamoDB Streams vs DynamoDB Time to Live (TTL):** DynamoDB TTL is a feature that automatically deletes expired items from a table. While TTL deletions do create a stream event, they are not immediate and can take up to 48 hours to process. DynamoDB Streams captures all mutations, including TTL deletions, but the two features serve different purposes: TTL manages data lifecycle, while streams capture change events. (Example: If you want to delete user sessions 24 hours after creation, use TTL. If you want to log every deletion for auditing, use DynamoDB Streams with a Lambda function.)
- **DynamoDB Streams vs DynamoDB Global Tables:** Global Tables is a multi-region replication solution that uses DynamoDB Streams under the hood. DynamoDB Streams is the mechanism that captures changes in one region and sends them to another region. Global Tables is a feature built on top of streams, not a replacement for them. You can use DynamoDB Streams independently for other purposes besides cross-region replication. (Example: Use DynamoDB Streams to trigger a Lambda function for sending notifications. Use Global Tables if you need your DynamoDB data available in multiple AWS regions.)
- **DynamoDB Streams vs Amazon DynamoDB Streams vs. AWS Database Migration Service (DMS):** DMS can be used for continuous replication of DynamoDB data to other databases, but it uses a different mechanism (CDC via DynamoDB Streams or API polling). DynamoDB Streams itself is the source for change data capture. DMS is a service that orchestrates the replication, while DynamoDB Streams is the data source. (Example: Use DynamoDB Streams if you want a lightweight, serverless way to react to changes. Use DMS if you need to migrate your entire DynamoDB table to another database engine.)

## Step-by-step breakdown

1. **Enable DynamoDB Streams on the table** — You must explicitly enable streams on a DynamoDB table. You can do this during table creation or afterward using the AWS Management Console, CLI, or SDK. At this point, you choose the StreamViewType, which determines what data is included in each stream record.
2. **Data modification occurs on the table** — When an application performs a PutItem, UpdateItem, or DeleteItem operation, DynamoDB writes the change to the table and also writes a stream record to the stream log. This happens synchronously and does not significantly affect write latency.
3. **Stream record is stored in a shard** — DynamoDB organizes stream records into shards based on the table's partition keys. Each shard contains a sequence of records that are ordered by the time of the change. The number of shards scales with the table's write capacity.
4. **Consumer polls or is triggered to read the stream** — A consumer, such as a Lambda function or a custom application using the DynamoDB Streams API, reads the stream records. For Lambda, you create an event source mapping that polls the stream periodically. For custom consumers, you call DescribeStream, GetShardIterator, and GetRecords.
5. **Consumer processes the stream records** — The consumer receives a batch of stream records. Each record contains the event type, keys, timestamp, and optionally the old and new images. The consumer can then take action, such as updating a cache, sending a notification, or aggregating data.
6. **Stream record expires after 24 hours** — If a stream record is not consumed within 24 hours, it is automatically deleted. This ensures that the stream does not consume unlimited storage. Consumers must be designed to read records within this window.

## Practical mini-lesson

DynamoDB Streams is a powerful tool for building event-driven systems, but it requires careful configuration and understanding of its constraints. As a professional, you will often use it alongside AWS Lambda to create reactive, serverless pipelines. The most critical decision is choosing the StreamViewType. Let's walk through a real-world scenario: an e-commerce platform that uses DynamoDB to store product data. The platform needs to update a search index (Amazon OpenSearch) whenever a product's price or availability changes. It also needs to send a notification to inventory management when an item is deleted. For the search index, you only need the new values after an update. So you should set StreamViewType to NEW_IMAGE. If you set it to NEW_AND_OLD_IMAGES, you will pay for unnecessary data. For the inventory management, you only need the item's key (product ID) when it is deleted. So you could use a separate stream consumer with KEYS_ONLY, but since the stream setup is per table, you can have one Lambda function handle both use cases by filtering on the event type and using the appropriate data from the stream record. Another practical consideration is error handling and retries. When a Lambda function fails to process a stream record (due to a bug or external service outage), the record is retried based on the event source mapping's configuration. If the retry fails multiple times, the record is discarded unless you configure an on-failure destination (like an SQS queue) to capture failed records. This is a best practice for production systems. You also need to consider the impact of Lambda concurrency. If your stream is high throughput and the Lambda function takes a long time to process each record, you may hit the Lambda concurrency limit and see throttling errors. To address this, you can increase the batch size so that more records are sent per invocation, or you can use a Kinesis Data Firehose to buffer the stream data and write it to S3 in batches. For cost optimization, remember that DynamoDB Streams has a free tier, but after that you pay per read request unit. The size of each stream record (determined by StreamViewType) directly impacts cost. A typical professional mistake is to leave StreamViewType as NEW_AND_OLD_IMAGES for all tables, which can double the read demand. Always default to the least detail you need. Finally, testing DynamoDB Streams in a development environment is straightforward. You can enable the stream, use the AWS Console to view recent shards, and even use the 'Poll for records' feature to see the raw data. For automated testing, you can simulate stream events using the AWS SDK. Understanding these practical details will help you design robust, cost-effective event-driven applications.

## Commands

```
aws dynamodb update-table --table-name MyTable --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
Enables DynamoDB Streams on an existing table with NEW_AND_OLD_IMAGES view type.

```
aws lambda create-event-source-mapping --function-name MyFunction --event-source arn:aws:dynamodb:us-east-1:123456789012:table/MyTable/stream/2024-01-01T00:00:00.000 --starting-position TRIM_HORIZON
```
Creates a Lambda event source mapping that polls DynamoDB Stream starting from the oldest available record.

```
aws dynamodb describe-stream --stream-arn arn:aws:dynamodb:us-east-1:123456789012:table/MyTable/stream/2024-01-01T00:00:00.000
```
Describes the stream, including shard IDs and stream status.

```
aws dynamodb list-streams --table-name MyTable
```
Lists all streams associated with a given DynamoDB table.

## Troubleshooting clues

- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined

## Memory tip

Think 'Stream View Types' as 'K O N' (Keys Only, Old Image, New Image) plus the combination NEW_AND_OLD. For ordering, remember 'shard = order', each shard is a queue, but queues don't talk to each other.

## FAQ

**Do I have to pay extra for DynamoDB Streams?**

DynamoDB Streams has a free tier of 2.5 million read request units per month. After that, you pay per read request unit. There is no cost for enabling the stream itself, only for reading records from it.

**Can I have multiple consumers reading the same DynamoDB Stream?**

Yes, multiple consumers can independently read the same stream. Each consumer uses its own event source mapping or its own shard iterators. The stream data is not consumed or deleted by one reader.

**What happens if a stream record is not consumed within 24 hours?**

The record is automatically deleted. DynamoDB Streams is not designed for long-term storage. You must process records within the retention window.

**Does DynamoDB Streams capture all changes, including those from TTL?**

Yes, TTL deletions are captured as stream events with event type REMOVE. However, TTL deletions are not immediate and can occur up to 48 hours after the TTL attribute expires.

**Can I disable and re-enable DynamoDB Streams on a table?**

Yes, you can disable and re-enable streams at any time. Disabling the stream stops writing new records and deletes all existing stream data. When you re-enable it, a new stream begins from the point of re-enablement.

**Is there a limit to how many stream records can be produced per second?**

The throughput of DynamoDB Streams is directly tied to the table's write capacity. The stream can handle up to 2 times the write capacity units of the table. There is no separate stream throughput limit.

**How do I troubleshoot a Lambda function that is failing to process stream records?**

Check the Lambda function's CloudWatch Logs for error messages. Ensure the function has the required IAM permissions for DynamoDB Streams and that the event source mapping is enabled. Also verify that the StreamViewType matches what the function expects.

## Summary

DynamoDB Streams is an indispensable feature for any developer working with DynamoDB in a modern, event-driven architecture. It provides a durable, ordered log of every change made to a DynamoDB table, enabling you to build reactive systems that respond to data modifications in near real time. The key takeaways are understanding how to enable streams, choosing the appropriate StreamViewType to balance cost and data completeness, and integrating with AWS Lambda or other consumers. You must remember the 24-hour retention limit and the fact that ordering is guaranteed only within a shard, not across shards. Common mistakes include assuming global ordering, selecting the wrong StreamViewType, and forgetting to configure proper IAM permissions. For the AWS Certified Developer – Associate exam, you can expect scenario-based questions that ask you to design change capture solutions, configure stream settings, and troubleshoot integration issues. Mastering DynamoDB Streams will not only help you pass the exam but also equip you with a practical skill for building scalable, serverless applications. The ability to decouple database writes from downstream processing is a fundamental tenet of cloud-native design, and DynamoDB Streams is the enabler of that pattern.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/dynamodb-streams