The Specification

Open Outbox Specification

The Goal

The Open Outbox Specification defines a universal, language-agnostic contract for the Transactional Outbox pattern.

In microservice architectures, the database outbox table is the critical “handshake” between your application logic and your message infrastructure. We believe this handshake should be standardized so that your choice of programming language doesn’t dictate your infrastructure’s reliability.

Core Objectives

Interoperability

A Go-based relay can process an outbox table populated by Python, Node.js, or Java apps without custom configuration.

Reliability

Mandates fields for idempotency (event_id), controlled retries (available_at), and state tracking.

Broker Affinity

Includes a partition_key field to ensure the target broker can maintain strict ordering and load balancing.

Agnostic

Works across different databases (Postgres, MySQL) and brokers (Kafka, NATS, Webhooks).

Why Standardize?

Most outbox setups are just custom code glued to a specific framework. By using a standard schema, teams can stop wasting time rebuilding the same polling loops, database locking, and retry logic from scratch.

Open Outbox moves this complexity into a shared standard. This allows developers to focus on publishing events, while the relay handles the heavy lifting of “at-least-once” delivery.

Formal Specification

The formal technical documentation—including strict SQL schema definitions, state transition diagrams, and metadata requirements—is maintained in a dedicated repository.

Roadmap to Stable Spec

Core Schema Definition (Postgres Reference)
State Machine Formalization (Handling PENDING, DELIVERING, DEAD)
Ordering & Partitioning Extensions
Multi-Database Dialects (MySQL, SQL Server, MongoDB)