Inbox pattern

The inbox records incoming message IDs and processing state in the consumer's database before side effects complete. Combined with at-least-once delivery, it prevents duplicate charges, double shipments, or repeated emails on redelivery.

Trade-off: extra storage and transactional overhead versus correct exactly-once side effects at the application level.

On interviews: explain processing flow: receive, insert inbox, work, mark done, ack broker; handle crash between steps.

Common pitfalls: ack before processing completes; inbox without unique constraint on message ID; never cleaning old inbox rows.

Checklist:

• Unique key on broker message ID or business idempotency key.
• Process in one transaction with domain update when possible.
• Ack only after durable processing record.
• Archive or TTL processed inbox entries.