What is a DynamoDB Stream, what does the StreamViewType setting control, and what ordering and retention guarantees does the stream give a consumer?

## What the stream is A DynamoDB Stream is a change log attached to a table. Once enabled, every item-level modification — a `PutItem` that creates an item, an `UpdateItem` that changes one attribute, a `DeleteItem`, an expiry performed by the table's Time to Live setting — produces one **stream record**. The stream is a separate API surface (`streams.dynamodb.<region>.amazonaws.com`) with its own operations such as `DescribeStream`, `GetShardIterator` and `GetRecords`, deliberately shaped like the Kinesis Data Streams API so the same client libraries can consume it. Enabling a stream is a table setting: ```bash aws dynamodb update-table \ --table-name Orders \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES ``` Streams are not billed by capacity units; you pay per read request against the stream, and writes to the table do not consume extra write capacity to populate it. ## StreamViewType: how much of the item travels Four values, chosen once per stream: - `KEYS_ONLY` — only the key attributes of the changed item. Smallest records; a consumer that needs the current value must read the table, which also means it sees the *latest* value rather than the value at the time of the change. - `NEW_IMAGE` — the entire item as it looks after the change. Good for projecting into a search index or a cache. - `OLD_IMAGE` — the entire item as it looked before. Good for audit trails of what was removed, and the only way to see the contents of a deleted item. - `NEW_AND_OLD_IMAGES` — both. The default choice for change-data-capture, replication and anything that must compute a diff, and what global tables uses internally. Changing the view type requires disabling and re-enabling the stream, which creates a new stream with a new ARN and loses whatever was in the old one, so it is worth getting right at design time. Each record also carries an `eventName` of `INSERT`, `MODIFY` or `REMOVE`, and for TTL expiries a `userIdentity` block identifying the principal as the DynamoDB service — the standard way to distinguish an expiry from a real user delete. ## Ordering: per item, not per table The stream is divided into **shards**, which correspond roughly to the table's partitions, and each shard is an ordered sequence. All changes to a given partition key land in the same shard lineage, so a consumer sees that item's history in the order the changes happened. Across different keys there is no ordering guarantee at all: an update to item A that happened before an update to item B may be read after it, because they are in different shards being consumed in parallel. This is the right guarantee for most use cases — you almost always care that one order's status transitions arrive in sequence, not that two unrelated orders are interleaved correctly — but it quietly breaks any design that assumes a global timeline, such as reconstructing a table-wide audit log by naive concatenation. Shards are also not permanent: they split and close as partitions split, and a consumer must follow the parent-child shard lineage. That bookkeeping is exactly what the Kinesis Client Library, or Lambda's managed poller, does for you. ## Retention and delivery semantics Stream data is retained for **24 hours**, after which it is deleted regardless of whether anyone read it. That single number drives a lot of operational design: a consumer that is broken over a weekend does not just lag, it loses data permanently. Monitoring consumer lag is therefore not optional, and a rebuild path that does not depend on the stream — re-scanning the table, or restoring from a backup — is a required part of any stream-based pipeline. Each change appears in the stream **exactly once**. Delivery to a consumer is **at least once**: retries, shard-iterator restarts and consumer restarts all cause records to be re-read. Consumers must be idempotent — key the downstream effect on something stable such as the item's key plus a version attribute, or the record's sequence number. ## Choosing the stream, or Kinesis instead DynamoDB also offers streaming a table's changes to a Kinesis Data Stream instead. That option trades guarantees for reach: it gives you longer, configurable retention and the whole Kinesis consumer ecosystem, but records may arrive out of order relative to the item's history and duplicates are possible, so it suits analytics fan-out more than replication. Native DynamoDB Streams are the choice when per-item ordering matters. ## What interviewers listen for Name the four view types and pick one for a stated purpose; state the 24-hour retention as a design constraint rather than a fact; and be precise about ordering — per partition key, not global. Adding that delivery is at-least-once and therefore handlers must be idempotent is usually the sentence that separates a real practitioner from someone who has read the feature page.