Streams Interview Questions

A time-ordered event for an item change: keys plus, depending on view type, old and/or new images, the event name (INSERT, MODIFY, REMOVE), and sequence metadata. Consumers use it to fan out search, caches, and workflows without putting that work on the request path.

KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, and NEW_AND_OLD_IMAGES. NEW_AND_OLD_IMAGES is the usual choice when consumers need diffs. KEYS_ONLY is cheaper but forces a follow-up Get, which may miss a deleted item. Pick the view before enabling; changing it is a stream replacement.

Records are available for 24 hours. If a consumer falls behind past that window, data is gone from the stream and you must backfill from the table or a longer store such as Kinesis Data Streams. Iterator age alarms exist so you notice before the window closes.

Set StreamSpecification with a view type on the table; status becomes ENABLED when shards are ready. Applications then subscribe via Lambda event source mappings or the Streams API. Enabling streams does not change Get/Query behavior for clients of the table.

A shard is an ordered sequence of records for a subset of the table’s partitions. Consumers must iterate each shard and handle parent/child shards after splits. Lambda’s event source mapping hides most of that; raw KCL-style consumers must not skip closed shards.

An event source mapping polls shards and batches records into invocations. You configure batch size, starting position, and failure handling (retries, bisect, destination on failure). The function must be idempotent because at-least-once delivery is the contract.

When you need longer retention, more than two consumers of the native stream, or richer fan-out with enhanced fan-out. Native DynamoDB Streams are simpler for a Lambda or two inside 24 hours. Kinesis adds cost and operational surface in exchange for durability of the change log.

Delivery is at least once: retries, overlapping batches, and Lambda redrives replay the same sequence numbers. Side effects (emails, charges, search upserts) need a processed-token or natural upsert. Exactly-once across the whole pipeline is an application property, not a stream guarantee.

IteratorAgeMilliseconds is the lag between now and the oldest unprocessed record. Rising age toward hours means you will hit the 24-hour cliff. Scale concurrency, fix slow downstream calls, or shrink batch work; ignoring age is how silent data loss starts.

Prefer one ordered consumer that publishes to SNS/EventBridge/Kinesis, or separate Lambda mappings if each is independently scalable and idempotent. Putting three outbound calls in the original API write couples latency and failures. Stream fan-out keeps the write path small.

Expired items appear as REMOVE events, often with a userIdentity type indicating the TTL service. Consumers that sync to search must delete the document. If you needed the old image, the stream view must include OLD_IMAGE or NEW_AND_OLD_IMAGES.

Filter on an attribute such as entityType in Lambda event filtering, or branch inside the handler. Filtering at the event source saves invocations. Do not Scan the table inside the stream function to decide; the record already has the image if you chose the right view.

A restore creates a new table; you enable streams there separately and consumers start from that table’s changes, not the old shard set. GSI backfill does not replay as user writes on the base stream. Plan cutover so consumers do not double-apply or miss the restore point.

Configure bisect-on-function-error, a bounded retry, and an on-failure destination (SQS/SNS) for poison records. Returning failure on the whole batch stalls that shard. Dropping errors silently desynchronizes search and billing from DynamoDB.

Cap parallelization, use batch windows, and isolate heavy consumers on Kinesis rather than three mappings each retrying the full stream. Watch iterator age per mapping. A warehouse loader that HTTP-calls per item will drown a high-churn table.

Records for the same partition key are ordered within their shard lineage. There is no global table order across partitions. Designs that need a total order must impose one in the application (per-key sequencing is the realistic promise).

Replay from a snapshot: Scan/export the table or read a longer Kinesis retention, then resume the live stream from a stored sequence. Mark a watermark so live and backfill do not double-write. Hoping the 24-hour buffer still has your outage is not a recovery plan.

Alarms on repeated failures for the same sequence number, bisect to a batch of one, and park that record on a DLQ with the keys in the payload. Fix the parser or the downstream schema, then replay. A single bad JSON field should not freeze the whole shard.

The API keeps writing DynamoDB; a stream consumer writes the new store. Switch reads when lag and reconciliation are acceptable, then stop. This strangler avoids two-write error handling in every endpoint, at the cost of replication lag you must measure.

dynamodb:DescribeStream, GetRecords, GetShardIterator, and ListStreams on the table’s stream ARN, plus Lambda invoke rights if mapped. Least privilege should not grant Scan on the table unless the consumer truly needs a backfill path. CloudTrail still records management events around stream configuration.