Flow
Decisions

0001 — Postgres is the source of truth

Each service owns one Postgres database as authoritative state.

Decided. Each service owns one Postgres database. It holds current state and is authoritative. Commands read it, validate against it, and write to it in one transaction.

Alternatives

  • Event log as the system of record (what the legacy deepsky does). Aggregates rehydrated by replaying a JetStream subject on every command.
  • Shared database across services. Rejected outright — no ownership, no independent deploy.

Why

The legacy system replays an aggregate's full event history on every command, has no snapshots implemented, enforces concurrency with NATS stream sequences rather than database constraints, and serves reads from an asynchronously updated projection with a staleness window. The result is that basic questions require specialised tooling, and read-your-writes does not hold.

With Postgres authoritative: a query is a SELECT, an invariant is a constraint, a concurrent write conflict is a unique index doing its job, and debugging is SQL.

Consequences

  • Recovery is PITR, not replay. WAL archiving and tested restores become required rather than optional.
  • Events are published from an outbox and are no longer the record. See 0004.
  • SELECT ... FOR UPDATE, unique indexes, and CHECK constraints replace application-level concurrency control.

On this page