Modern applications rarely do just one thing at a time.

An API request creates an order, and then another service needs to reserve stock, another to charge the customer, another to send an email, and so on. In a serverless or event-driven architecture, follow-up actions are usually triggered by messages (either events or commands).

That gives us loose coupling, better scalability, and independent services. But it also introduces a reliability problem.

“What happens when the database update succeeds, but publishing the event fails?”

Or the opposite:

“What happens when a consumer processes an event successfully, but crashes before acknowledging it?”

This is where the Outbox Pattern and Inbox Pattern come in.

The TL;DR is:

• Outbox Pattern: ensure state changes reliably produce events.
• Inbox Pattern: ensure incoming events are processed safely, even when they are delivered multiple times.

They are often used together to build reliable event processing flows.

The problem with naive event publishing

Imagine an Orders service that stores orders in DynamoDB and publishes an OrderCreated event to EventBridge.

The simplest implementation might look like this:

This looks fine, but it has a failure case.

Now, the order exists, but the event was never published.

Downstream services do not know the order exists. Inventory is not reserved. Payment is not started. The customer does not receive a confirmation email.

The mistake here is treating the database write and the event publish as if they are one atomic operation. They are not.

This is a distributed transaction problem.

The Outbox Pattern

The Outbox pattern solves the “database updated but event not published” problem.

Instead of writing to the database and then immediately publishing to EventBridge, the service writes both the order and the outgoing event (the outbox item) in a single database transaction.

Later on, another process will pick up the outbox item and publish it to EventBridge asynchronously.

The idea is simple: first persist the intent to publish, then publish later.

You can easily implement the Outbox pattern with DynamoDB and EventBridge Pipes.

For example, you’d have an Orders table and an Outbox table and use TransactWriteItems to write both records atomically.

From here, DynamoDB Streams captures the INSERT events from the Outbox table. EventBridge Pipes reads from the stream, optionally filters and enriches the records, then sends matching records to an EventBridge event bus. All without writing any custom glue code.

A raw DynamoDB stream record is a database change notification. It contains DynamoDB-specific structure, such as NewImage, OldImage, keys, and attribute types.

That is not what you want downstream services to consume.

Instead, the pipe should transform the DynamoDB INSERT event into a clean domain event before sending it to EventBridge. Also, don’t forget to wrap the event in an envelope so you can capture important metadata with the event payload.

There are many variations to this basic pattern.

For example, you may replace EventBridge Pipes with a Lambda function if the publishing step has real business logic.

Or you may forego the Outbox table altogether and derive the outgoing event from the inserted Order item. However, if you wish to track the status of the outbox item (e.g. from PENDING to PUBLISHED), then this is not a viable option.

The Inbox Pattern

The Inbox pattern solves the duplicate delivery problem on the consumer side.

Most event and messaging systems should be treated as at least once delivery systems from the application’s point of view. Even if the infrastructure reduces duplicates, your business logic should still assume duplicates are possible.

This is especially true for Lambda, because all async invocations (e.g. via EventBridge or SNS) have at least-once delivery.

Without protection, the payment service might charge the customer twice!

The Inbox Pattern prevents that by recording which messages have already been processed.

The consumer stores the incoming event ID in an Inbox table, and the inbox item then acts as a deduplication key.

The key to implementing this pattern with DynamoDB is to use conditional writes to ensure the event ID does not exist in the Inbox table already.

Inbox vs. Idempotency

You might be wondering,

“How is this different from using simple idempotency keys?”

These are related ideas that mainly differ in scope.

An idempotency key protects one business operation. Whereas the Inbox pattern protects message processing.

Within one message processing, there might be several business operations, each with its own idempotency key.

The Inbox pattern is idempotency applied at the message processing boundary, using the message/event ID as the deduplication key.

Inbox item first, or business update first?

Avoid this flow:

1. Write inbox item.
2. Commit.
3. Perform business update.

If step 1 succeeds and step 3 fails, future retries will see the inbox item and skip processing, even though the business action never happened.

Also, avoid this flow:

1. Perform business update.
2. Commit.
3. Write inbox item.

If step 1 succeeds and step 3 fails, future retries may repeat the business action.

The safest solution is to write the inbox item and business change in the same transaction.

But what if that’s not possible? For example, what if there are intermediate side-effecting actions, such as calling a third-party API?

In that case, this is a safer flow:

1. Try to write the inbox item with status = PROCESSING and a lock expiration.
2. If the insert succeeds, this worker owns the event.
3. If the insert fails, another worker has already claimed or processed it.
4. Only the owner performs side effects.
5. Mark the inbox item as PROCESSED.

If the first worker fails or times out, a subsequent retry can resume processing after the lock has expired.

But what about the side effects that the first worker has already performed?

That’s where we also need idempotency keys to protect the individual side-effecting actions!

Final thoughts

Most real-world event-driven systems have both consumers and producers.

For example, the payment service consumes OrderCreated and publishes PaymentSucceeded or PaymentFailed events.

That means it needs both patterns:

• Producers use the Outbox pattern to ensure events are reliably published.
• Consumers use the Inbox pattern to ensure exactly-once message processing.

These patterns are not about making failures impossible. They are about making failures safe.

The Outbox pattern accepts that publishing can fail, so it first stores the intent to publish.

The Inbox pattern accepts that duplicate deliveries can happen, so it makes message handling idempotent.

Together, they give you a strong foundation for reliable event processing.

Related articles

• ​EventBridge best practice: why you should wrap events in event envelopes​
• ​Event versioning strategies for event-driven architectures​
• ​Event-Driven Architectures: How to limit the scope of end-to-end tests​
• ​How to reprocess Lambda dead-letter queue messages on-demand​
• ​Understanding push vs poll in event-driven architectures​
• ​When to use Light Events vs. Rich Events in Event-Driven Architectures​