Writing
Notes from systems meeting real devices.
Notes on payment systems, device software, transaction uncertainty, platform design, and the emerging role of AI in commerce. I write from the questions that appear in real operating conditions.
Reversal and retry: designing inverse operations that don't lie
Retry-safe means idempotency-key aware. Reversal-safe means preserving the original approval alongside the reversal. Neither is the default.
Building a connector abstraction layer
Every payment platform ends up with a connector abstraction. The design choices that make one durable, and the ones that guarantee it will be rewritten in 18 months.
Reconciliation as a first-class service
Reconciliation gets treated as a nightly batch afterthought. Elevating it to a first-class service changes what the rest of the platform can guarantee.
Idempotency keys: implementation patterns
Every payment API documents idempotency keys. Every payment platform gets some of the details wrong. A pattern guide.
Event sourcing for transaction platforms
Event sourcing is often oversold. For a payment transaction platform, though, its properties align well — with some carve-outs.
Handling partial reversals
Full reversals are well-covered in most integrations. Partial reversals are where the design assumptions leak.
The reporting store vs. the transaction store
One database can serve both operational and reporting queries — until it can't. Where the split should go and how to build it.
Database sharding for authorization pipelines
Sharding a database is often the wrong first move. When it isn't, the choice of shard key is the decision you can't undo.
Scaling settlement batching
Settlement batching sounds like accounting. It's actually a distributed systems problem with financial-grade correctness requirements.
Cross-region failover for payment platforms
Cross-region failover for a payment platform has different constraints from a general web application. What the design has to preserve.