A Thousand Transactions at Once — My Java Stress Test

BankEngine, pushed January 29, 2026, was where my concurrency coursework stopped being theoretical. The goal was ambitious for a student repo: simulate a banking engine handling 1,000+ concurrent transactions without race conditions, using Java, Executors, ConcurrentHashMap, and ReentrantLock with fairness policies. I wanted to see failure modes in daylight — duplicate transfers, inconsistent balances, threads starving each other — and then design guards that actually held. Debugging was humbling; Heisenbugs do not care about your GPA. Each fix required reading JVM behavior more carefully than any lecture slide demanded. When the engine finally sustained load without corrupting state, I felt a different kind of pride than shipping a UI feature. This was systems thinking in the raw. BankEngine also balanced my AI-heavy timeline with classical engineering credibility. Not everything I build needs a transformer. Some milestones need locks, metrics, and reproducible tests. Recruiters ask about scale — this repo is my answer at the learning scale: I understand what breaks when everyone runs at once. It reminded me why fundamentals still matter in an LLM-heavy world. Load tests do not lie, and that is why I loved this repo. It gave me vocabulary for interviews: fairness, starvation, throughput, invariants — words that feel solid when LLM hype is everywhere. BankEngine is my reminder that threads, locks, and invariants still run the world underneath every chatbot interface.