The outbox pattern with DynamoDB solves a problem I deliberately left open in part 1 of this series . There, the intake function first writes a job to DynamoDB and then sends a message to SQS. Most of the time that works. If the function dies exactly between the two calls, though, a job sits in PENDING forever and nobody ever processes it. Gaps like this never show up in tests, but sooner or later they will show up in production.

In this part I close that gap without writing a single line of glue code for forwarding. The intake function only writes to the table. An EventBridge pipe turns the table’s change stream into the message for the worker, and a second pipe announces finished reports as a domain event on an event bus. The example is once again the fictional bookshop with its stock reports, this time built and tested entirely with the AWS CDK.

In short

With the outbox pattern, the application only writes to its database, and a separate process reliably turns those writes into messages.…