# Outbox Pattern

> Guarantee event delivery by staging events in the DB before the broker — atomicity by design.

- **Category**: Microservices
- **Subcategory**: Resilience
- **Canonical URL**: https://designpattern.fyi/patterns/outbox_pattern/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Payment Service processes a charge. Atomically: UPDATE payment_records + INSERT INTO outbox (PaymentProcessed event). Relay sends to SQS. Order Service consumes idempotently. No lost payments, no double-charges, even under load.





## Trade-offs


### Advantages

- Transactional integrity — state change and event are atomic

- Reliable delivery — events survive broker downtime

- Works under load — no silent message loss

- Standard pattern, well-supported by tooling (Debezium, etc.)




### Considerations & Drawbacks

- Additional OUTBOX table in every service's schema

- Relay/publisher process needs deployment and monitoring

- Adds latency between commit and broker delivery

- Outbox table needs periodic cleanup







---
**Reference**: [Original Source](https://www.factualminds.com/blog/microservices-design-patterns-aws-production-guide-2026)