33/60 Days System Design Questions

A daily.dev post from Joud Awad, day 33 of a 60-day system design series, frames a concrete failure: an order service backed by Postgres stores only current state, so every overwritten row erases how an order got there. A billing dispute surfaces the gap directly, with two orders sharing an ID and different totals and no way to reconstruct what happened.

Fichamento

#

• The failure case: an order service taking 200 writes/sec, backed by Postgres storing current state only, with every UPDATE overwriting the previous row and no audit log, event history, or replay.
• The trigger: a billing dispute over Order #8471, where the current schema can’t reconstruct what actually happened to that order over time.
• Four options are on the table: event sourcing (append-only log, state derived by replaying events), change data capture streaming Postgres row changes to Kafka, a trigger-based audit_log table, and dual-write to both a current-state table and a separate events table.
• The post treats event sourcing as the only option that gives full replay and projection flexibility, framing CDC, audit tables, and dual-write as patches rather than a real source of truth.
• The CQRS note covers the pairing this scenario assumes: event sourcing fits naturally with a separated read/write model, since state changes are stored as a sequence of events rather than as current state.