Payments, architecture, written down.
Ledger design, idempotency, event-driven payments, and AI engineering — from someone who shipped the systems, not surveyed them from a slide.
This is a working notebook, not a marketing blog. Every post here comes out of a system I actually built or broke: a ledger that had to survive a retried payment, an integration that had to reconcile two banks' idea of "settled," an agent-banking rail where the same callback could legitimately arrive twice. The posts are written for the engineer who has to make the same call under the same constraints. They are not for a general audience skimming for buzzwords.
What this covers
Three threads run through everything published here.
- Ledger design: how you structure the write path so that money movement is auditable, reversible, and safe to retry. It is the discipline behind idempotency keys, double-entry postings, and reconciliation jobs that don't lie.
- Event-driven payments: what happens when a payment isn't one request-response call but a chain of webhooks, callbacks, and asynchronous settlement events. They can arrive out of order, twice, or not at all.
- AI engineering applied to the same domain: where a model earns a place in a payments or lending pipeline, and where it emphatically does not.
Each post follows the same rule: state the mechanism everyone already agrees on, then show where it actually breaks in production and what closes the gap. No invented case studies, no "in today's fast-paced world" filler — just the decision, the failure mode it was made to prevent, and the trade-off it cost.
Who it's for
- Backend and platform engineers building or reviewing a payments, lending, or wallet system.
- Architects who need the failure-mode vocabulary to push back on a shallow "we cache the response" design.
- Anyone who has been paged for a duplicate charge and wants to know why the fix has to live at the ledger write, not the API gateway.
Never Reuse a Release Tag: One Overwritten Image, One Burned Version
Why a reused Docker image tag slips past Kubernetes, when reusing a deleted release's tag is safe, and what a release pipeline should enforce instead.
Passed All Tests in Integration and Acceptance, Then Broke Production
Why payment releases that pass integration and acceptance tests still break in production: config drift between environments that different teams own.
Idempotency Keys in Payment APIs: Safe Retries Without Double Charges
How idempotency keys stop payment retries from double-charging — and why the key has to be enforced at the ledger write, not just cached at the API gateway.
Working through ledger design, event-driven payments, and PCI tokenization next. If there's a payments or architecture question you want answered from the trenches, email avikganguly010@gmail.com and I'll put it on the list.