Full-stack banking platform built with Spring Boot and React, focused on transaction correctness, double-entry accounting, concurrency safety, idempotent payments, security, and auditability.
Double Ledger models money movement as immutable ledger entries where account balance is derived from transaction history rather than stored as the primary truth.
The problem
Banking workflows must remain correct under retries, concurrency, and partial failures. The system is engineered for consistency, idempotency, and auditable security boundaries.
Technical deep dive
How the system holds together.
Core engineering
Every transfer creates DEBIT + CREDIT entries tied to one transaction reference. Transaction -> Ledger Entries -> Derived Balance keeps accounting traceable and deterministic.
Concurrency and idempotency
Deterministic ascending account lock order with pessimistic locking reduces deadlocks while persisted idempotency state and keys make UPI retries safe.
Security and auditability
Short-lived JWT + refresh-token rotation stored hashed, RBAC across five roles, sender ownership/KYC checks, audit logging, access logs, and session controls enforce trust boundaries.
Diagrams
System surfaces.
ARCHITECTURESystem Architecture
LEDGERDouble-Entry Ledger
CONCURRENCYConcurrency and Locking
TRANSACTIONFund Transfer Flow
IDEMPOTENCYIdempotency
AUTHENTICATIONAuthentication and RBAC
DATABASEDatabase Design
DEPLOYMENTDeployment
Engineering decisions
Why I made these decisions.
Why double-entry ledger?
An immutable debit-credit ledger provides traceability, reconciliation, and correctness under complex transaction flows.
Why deterministic pessimistic locking?
Locking shared accounts in ascending ID order reduces deadlock risk during concurrent transfer execution.
Why idempotent UPI processing?
Persisted idempotency state ensures retried payment requests return the same result without duplicate debits.
Testing
Focused on business correctness across transfer validation, authorization, retries, and concurrency-sensitive flows with API-driven verification.
Deployment & DevOps
Frontend on Vercel, backend on Render, PostgreSQL on Neon, and CI/CD via GitHub Actions with Dockerized delivery steps.
What I learned
Lessons that travel.
Balance should be derived from ledger truth.
Concurrency safety must be designed explicitly.
Idempotency is mandatory for retryable financial actions.
