OutTransactional Outbox — Go + PostgreSQLEngineering case study
PUBLIC · RELIABILITY

Transactional Outbox — Go + PostgreSQL

A focused reference implementation for reliable event publication across transactional boundaries.

PublicGoPostgreSQLAt-least-once delivery

The problem

Why this project exists

The dual-write window can leave business state committed while its corresponding event is missing. The transactional outbox pattern moves event durability into the same database transaction.

Verified capabilities

What is actually implemented

These capability descriptions are intentionally limited to the evidence-backed implementation surface.

01

Atomic transaction

Order state and its corresponding outbox event are committed together.

02

Claiming

PostgreSQL FOR UPDATE SKIP LOCKED and a short claim lease support concurrent relays.

03

Retries

Transient publisher failures use bounded exponential backoff.

04

Idempotent consumer

Processed event state is keyed by consumer and event ID.

05

Ordering

Per-aggregate sequence data makes ordering an explicit downstream concern.

06

Failure semantics

Duplicate publication after a relay crash remains an explicit at-least-once scenario.

Architecture

How the system is structured

The diagram below represents the current verified architecture boundary; planned or environment-dependent components are described in the engineering notes rather than silently promoted.

HTTP API
↓
Order Service
↓
PostgreSQL
↓
Outbox Relay
↓
Publisher
↓
Broker
↓
Idempotent Consumer
BOUNDARY

Evidence and authority

The transaction closes the business-state/event durability window.

Tests cover validation, rollback, relay behavior, retries, HTTP validation and idempotency.

Engineering deep dive

Decisions, trade-offs and boundaries

Technology names matter less than the engineering contracts they enforce.

E1

The transaction closes the business-state/event durability window.

E2

Short relay leases reduce concurrent ownership conflicts without claiming duplicates are impossible.

E3

Consumer idempotency is a separate boundary from event publication.

E4

Tests cover validation, rollback, relay behavior, retries, HTTP validation and idempotency.

Project status

Public · evidence-backed status

Focused reference implementation with Go domain/application layers, PostgreSQL migrations, relay semantics, HTTP API, Docker Compose and tests.

ClassificationPublic implementation
EvidenceRepository implementation, tests and project records cross-checked
ClaimsCurrent, planned and limitations kept separate
DeploymentNot changed by portfolio integration
PUBLIC IMPLEMENTATION

Inspect the implementation directly.

Public implementation — source and architecture documentation are available.