Systems Writing

The discipline shelf: how production systems earn the word “boring” — architecture that survives scale, events that replay safely, migrations nobody notices, and databases that let you sleep.

Reading order if you are starting cold: Event-Driven Pitfalls for the distributed-systems tuition, then Zero-Downtime Migration for the method that makes legacy systems touchable again, then keep Postgres in Production within arm’s reach of whoever carries the pager.

The through-line across all of it: excitement is a defect. Every article here is a way of buying boredom — and boredom, in systems that move money, is the entire product.

If you only read one: the migration article, because it converts the sentence “we can’t touch that system” from a constraint into a project with a start date.

Double-Entry for Engineers Double-entry explained as an invariant system rather than accounting jargon: a five-hundred-year-old consistency protocol that assumes humans make mistakes. Ledger Design Why double-entry wins for any product that moves money, and what goes wrong the moment you try to store balances instead of deriving them from the entries. Reconciliation at Scale Matching millions of transactions nightly without a queue of unresolved breaks: how to rank exceptions by value and resolve them from a guided audit workflow. Event-Driven Pitfalls Ordering, replay and poison messages are the three failures that ruin most event-driven systems. What to design in first, and which guarantees you can skip. Postgres in Production Indexes, vacuum and lock contention: the three things that decide whether Postgres stays fast at scale, and how to spot each one before it takes the site down. Zero-Downtime Migration Dual-write and backfill, done in the right order. A practical sequence for moving a live database without a maintenance window or a nervous rollback plan. Why Your Ledger Drifts Ledger drift is never random. Where the difference actually comes from, how to prove it with a reconciliation query, and what to change so it cannot recur. The T+1 Problem Settlement time and business reality rarely agree. How to model T+1 properly so your customer balance, your bank statement and your ledger tell one story. Idempotency, Done Right Keys, time windows and where to store them. How to make a payments API safely retryable without quietly double-charging a customer during a network failure.