When Seconds Matter: A Real-Time Go Application for Secure Ledger Transactions

Khyati Tiwari — Fri, 19 Jun 2026 08:38:13 +0000

One of my biggest lessons in building secure applications was when I decided I wanted to build a fintech application. An overly complex fintech app would require access to sensitive data which had its legal complications so I stuck with a simple wallet application with a payment feature.

When building a financial application, data consistency isn't just a feature; it's a hard requirement. If a user transfers $50 from Account A to Account B, two distinct actions must happen simultaneously: Account A must be debited, and Account B must be credited. If the user double-clicks the "Send" button, or if two separate transactions hit the database at the exact same millisecond, the system can suffer from race conditions. If your backend executes these queries independently under default database isolation levels, high concurrency introduces severe vulnerabilities.

To ensure absolute financial accuracy, I implemented a strict double-entry ledger system. Every time a transfer occurs, the application must:

Debit the amount from Account A.
Credit the amount to Account B.
Update the running balances for both accounts.

To execute this safely under heavy concurrent traffic, I chose PostgreSQL's Serializable Isolation which guarantees that if transactions execute concurrently, the end result will be exactly the same as if they had run one after the other in a serialized line.

The Concurrency Roadblock: Handling SQLSTATE 40001

To enforce this, Postgres monitors the data reads and writes. If it detects that two concurrent transactions are modifying overlapping data sets in a way that would break this linear guarantee, it steps in aggressively to protect data integrity. Instead of allowing a race condition, Postgres intentionally terminates one of the transactions and throws a specific serialization failure error: SQLSTATE 40001.

The Go Solution: 10-Step Exponential Backoff

Since the database kills the transaction to safeguard the ledger, the responsibility shifts entirely to the Go backend to heal the operation.

If it catches 40001, it treats it as a temporary concurrency conflict rather than a terminal failure. The application then automatically retries the entire database transaction using an exponential backoff strategy.

The Go server attempts this loop up to 10 times. If the data clears up during any of these attempts, the transaction commits successfully, and the user experiences a seamless transfer without ever knowing a backend collision occurred. However, if the database is under catastrophic conflict and all 10 attempts are completely exhausted, the error is wrapped, and the application layer safely falls back to a generic HTTP 500 internal server error to ensure the system fails closed rather than corrupting data.

Aside from this, I enhanced the security of my application by employing several security standards :

Authentication Layers
The application enforces granular security by splitting user interactions into specialized operational layers:
Web Banking Password: A robust alphanumeric password for primary account login.
4-Digit View PIN: A low-friction PIN for safely viewing account balances.
6-Digit Payment PIN: A high-security PIN required specifically for authorizing outbound ledger transfers.

Hashing
To ensure data privacy, the Go backend implements Bcrypt hashing with a secure work factor for all credentials. The database stores only non-reversible cryptographic strings, rendering stored credentials useless in the event of a database compromise.

Multi-Factor Authentication (MFA)
To protect against credential stuffing, the application mandates MFA via TOTP (Time-based One-Time Password) algorithms. Users link their profiles to authenticator apps, and the backend verifies 6-digit tokens for sensitive sessions, preventing unauthorized access even if primary passwords are leaked.

Building this app taught me the role of databases in ensuring security in high stakes applications and I am certain that I can upgrade it with more features in the future.
You can test the Digital Wallet at : https://github.com/khyahahati/digital-wallet

Is FastAPI the best choice to build a Backend Entry Point?

Khyati Tiwari — Thu, 11 Jun 2026 16:50:25 +0000

Starting with placements around last year, the first project I built was a FastAPI-based API gateway. Essentially, what the gateway ensures is that only authenticated traffic reaches backend services alongside enforcing traffic control and observability standards.

It handles authentication, rate limiting, logging, and request routing before forwarding traffic to internal services and I'm not just naming features, they help solve some major pain-points while building a reliable backend.

Mobile and web apps have to keep track of multiple URLs and if you move a service to a new server, you have to update the client-side code and force a redeploy.
Now, because of the routing and proxying feature, there is only one URL. Moreover, the Gateway acts as the traffic controller, mapping requests to the right place.
Each microservice has the same authentication logic and if a security vulnerability is found in how you verify tokens, you have to patch and redeploy every service in your ecosystem.
The Gateway verifies the JWT once. If it’s valid, it passes the request to the backend with a header. As a result, the backend services can focus purely on business logic instead of security.
A single user/script bug can send 10,000 requests per second — crashing the database and causing DOS for all other users.
The Gateway counts requests in real-time and as soon as a user crosses their limit the gateway returns an HTTP Status 429.
Digging through five different sets of server logs across five different machines to piece together what went wrong with an error.
Every request sent is logged in a consistent format at the entry point including the full path, the response time, and the status codes improving debugging speed by 10x.
You don’t know your system is slow until support tickets are raised, no data on peak traffic hours or which services are struggling.
A real-time dashboard. You can see the heartbeat of your system. For example, if your average response time climbs from 50ms to 500ms, an automated alert can notify you before the system crashes.

I chose FastAPI because of concurrency. Since the gateway waits for the backend to respond, FastAPI’s asynchronous capabilities allow it to handle these waiting states without the consumption of any extra memory.

What my concern is whether this API Gateway is truly good enough to be used in production-grade applications. Am I missing some features or issues that arise with handling backend systems? I would love some opinions.

You can test the API Gateway here : https://github.com/khyahahati/api-gateway

Happy to hear your thoughts!

DEV Community: Khyati Tiwari

When Seconds Matter: A Real-Time Go Application for Secure Ledger Transactions

Is FastAPI the best choice to build a Backend Entry Point?