🏩 “No Half Transactions” — The Core Rules Behind Real Banking Systems

Bank Core Engineering When you build banking software, you don’t design for success.
You design for failure — and how to undo it cleanly.


💡 The Golden Rule

Every operation must either fully happen, or not happen at all.

No half-debit. No ghost balance.
If anything in the chain fails — we roll back.


🔄 Transactional Everything

Every POST request is wrapped in a database transaction.
Every balance update, fund transfer, or log entry happens atomically.

If any part throws an error, the transaction cancels —
no partial data ever hits the table.

That’s how you guarantee consistency.


🔐 Locking with Optimism

We use optimistic locking to keep things safe but fast.

Each account row carries a version key.
When two users try to update the same record,
only one wins — the other sees a conflict and retries.

No deadlocks, no stale data, no “double withdrawals.”
Just pure, version-aware concurrency.


đŸš« Idempotency — Protection from Double Taps

Every transfer request carries an idempotency key.
If a user hits “Transfer” twice,
the backend checks that key before executing anything.

If the key already exists — we skip execution.
No second debit. No accidental duplicate transaction.

It’s a simple layer that stops real-world chaos
(like lag, refresh, or retry) from breaking integrity.


⚠ Rollback by Default

If something looks wrong, we don’t try to fix forward.
We roll back instantly — every single table and change.

That’s how banks keep their ledgers trustworthy.
You don’t patch; you revert.


đŸ’Ÿ What About WAL?

PostgreSQL and most relational databases rely on a Write-Ahead Log (WAL) —
a system that records every change before it’s applied.

That means if the server crashes mid-transaction,
the database can replay or undo exactly what happened.
It’s like a time machine for data —
nothing is lost, nothing is half-written.


🧠 The Mindset

We don’t design around “what if it works.”
We design around “what if it doesn’t.”

If anything fails — rollback.
If a duplicate hits — ignore.
If concurrency collides — retry.
If it can’t guarantee safety — it doesn’t run.


It’s not fancy, it’s not “cloud-native,”
but it’s how you build software that people trust with their salary.

Because in banking, speed matters less than integrity —
and integrity is just another word for atomic truth.

© 2025 Patrick Kwon. All rights reserved.