React when a record changes — DynamoDB Streams and Lambda

Your goal

Plan a handler that reacts when an order record changes.

Why this matters

The shipping team wants to hear when an order becomes paid. You will choose change records, include the fields the handler needs, and make repeated processing safe.

Words you will use

A stream is a sequence of changes. A stream record describes one item change. An image is a copy of the item before or after that change.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Follow changes instead of guessing

Your orders table changes throughout the day. A shipping handler needs to react to updates rather than scan the whole table every minute. Choose a change source.

What can capture item changes?

A DynamoDB stream for the table.

DynamoDB Streams records item changes when enabled. A consumer can process those records. This is a bounded change log, not a permanent archive of every change for all time.

The handler has a stream of table changes to read.

Table write → stream record → consumer

2. Include useful before and after data

The handler must notice a move from pending to paid. Keys alone identify an order but do not show both states. Choose the useful stream-view information.

What should the change record include?

The old and new item images when needed.

Choose a stream view that includes the data your handler needs. Old and new images let it compare states, rather than treating every update as a new paid order.

The handler can recognize the intended state transition.

Old status=pending → new status=paid → eligible work

3. Handle a repeated attempt

A batch is retried after a worker failure. The handler may encounter work it already started. Choose a safe way to avoid sending the same shipping job twice.

What should the handler do?

Track stable work IDs and make side effects safe to repeat.

A change record and its processing are different things. Retries can repeat processing. Use a durable work ID and careful update logic so another attempt does not repeat an irreversible action.

The handler can retry without duplicating the shipping job.

Event/order ID → work check → safe processing → completion

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.