Ledger rail
Payment events kept getting lost between services.
The route.
How a request moves through the system, stop by stop. Illustrative, like the rest of this concept.
- Checkout
- Payments API
- Idempotency
- Ledger
- Reconciliation
- Payout
- Type
- Studio concept
- Category
- Payments infrastructure
- Our role
- Architecture and backend engineering
- Outcome
- Not applicable. Concepts don't get to claim results.
01
Overview
Ledger rail is a studio concept for a platform taking payments across several providers and banks. It turns a fragile chain of webhooks into a pipeline where every event is recorded, every effect happens once, and failures can be replayed safely.
02
The challenge
Providers retry, banks time out, and services restart mid-request. Money has to end up in exactly one place, and finance has to be able to prove it.
03
Scope
- Audit of the existing flow
- Outbox and event design
- Idempotent handlers
- Replay tooling
- Reconciliation reports
04
Technical decisions
- Write the event with the change.State changes and outgoing events commit in one transaction, so nothing is sent that didn't happen.
- Idempotency keys everywhere.Every handler can run twice without charging twice. Retries become boring.
- Replay is a feature, not an incident.Operators can replay any event from a console, with a dry run first.
begin;
update payments set state = 'captured' where id = $1;
insert into outbox (topic, key, body)
values ('payment.captured', $1, $2);
commit;05
Deliverables
- Payment pipeline
- Replay console
- Reconciliation reports
- Failure-mode runbooks
- Architecture decision records
Technologies
Next studio concept.
Multi-site operations SaaS
Got something complicated?
Tell us what you're building. You'll hear back from an engineer, not a sales team.