Building Offline UPI Payment System in Java with Spring Boot

Started Day 2 on my offline-first UPI payment system in Java + Spring Boot. Today’s focus was moving beyond basic money transfer APIs into something real products need: transaction history. Built a recent transactions endpoint that returns the last activity for a user instead of dumping raw database rows. Also started shaping responses through DTO mapping so customers only see relevant data like amount, status, counterparty, and transaction type (Sent / Received) — not internal fields. One underrated part of backend development: debugging response serialization, mapping layers, and edge cases often takes more effort than writing the endpoint itself. That’s where real learning happens. Current progress: ✅ Account creation API ✅ Payment transfer API ✅ Custom exception handling ✅ Transaction history feature in progress ✅ DTO-based response design Next steps: Finish transaction history cleanly Add timestamps JWT auth layer Idempotency for duplicate payment prevention PostgreSQL migration from H2 Building with a product mindset, not just CRUD. #Java #SpringBoot #BackendDevelopment #SystemDesign #FinTech #BuildInPublic #backenddev #SpringAI #SpringdataJPA #microservices

Recently, working on banking applications made me appreciate scalability even more. That makes it authentic. Writing code is one thing. Writing scalable code is another. Working with Java and Spring Boot in backend development has taught me that building APIs is not just about making them work — it’s about making them secure, maintainable, and scalable. One thing I’ve been focusing on improving is REST API design, because good API design impacts everything downstream. Still learning every day and enjoying the process. For backend developers here — what concept improved your coding the most? #Java #Springboot #BackendDevelopment #Microservices #SoftwareEngineering

We had to switch payment gateways last year. The actual payment logic? Didn't change. Same amount, same customer, same order. What broke everything was this: Service A wanted different JSON format: Service B wanted different JSON format Same data. Completely different shape. And both want the amount in cents, not dollars. And both have their own status codes in the response — Service A returns "succeeded", Service B returns "captured" our service used 0 and 1. Both mean SUCCESS on our end. So we ended up with two DTOs, two mappers, and two places to break. I got tired of this and built a library that handles it differently. You just define the mapping once in a config file. Want to switch to Service A? Change one word. That's it. But the part I'm most happy with is transforms. The transforms handle the messy parts. Dollar to cents, status code normalization, phone masking — you register them once and reuse across every mapping. Works on the response side too. Their status codes map back to yours automatically. No new DTOs. No new mappers. Just a config file. I know this isn't a groundbreaking computer science problem, but it's the kind of thing that wastes hours every few months in almost every backend project I've seen. Built it in Spring Boot. Happy to share the repo if anyone wants to take a look or give feedback. Here is repo link if you want to use it: https://lnkd.in/geYginqf #Java #SpringBoot #Backend #OpenSource

Excited to share a project I have been working on — FinFlow, a production-inspired banking backend built with Java and Spring Boot. The goal was simple: go beyond tutorial-level projects and build something that reflects real backend engineering challenges. What FinFlow covers: 🔐 JWT Authentication — stateless session management, BCrypt password encoding, and a custom Spring Security filter chain 💸 Money Transfers — idempotency via Redis key tracking, deadlock-safe pessimistic locking with ordered lock acquisition, and atomic balance updates 📨 Event-driven Fraud Detection — Kafka-based async pipeline with a dedicated thread pool, performing high-frequency, odd-hour, and card-testing checks without impacting transaction response time ⚙️ Batch Processing — asynchronous job execution using CompletableFuture with Redisson distributed locking to prevent duplicate processing 🛡️ Resilience — Resilience4j circuit breakers with a Facade pattern, and distributed rate limiting using Bucket4j backed by Redis 🧪 Unit Testing — JUnit 5 and Mockito covering success and failure paths of core transaction logic A few challenges worth mentioning: 🔄 Resolved a circular dependency between SecurityConfig and UserService by extracting PasswordEncoder to a separate configuration class — a good reminder that Spring's bean lifecycle requires deliberate design 🔒 Prevented deadlocks in concurrent transfers by enforcing ordered lock acquisition — always locking the lower account ID first regardless of transfer direction, making a circular wait impossible Every design decision in this project has a deliberate justification — from choosing Redisson over raw Redis for locking, to using a Facade layer to separate resilience concerns from business logic. The repository is available on GitHub — feel free to explore: https://lnkd.in/gRisUBED #Java #SpringBoot #BackendDevelopment #OpenToWork #SpringSecurity #Kafka #Redis #SystemDesign

Day 3 of Building an Offline UPI Payment System with Spring Boot Today I implemented idempotency in the payment flow using a unique requestId, while also studying the importance of concurrency handling in payment systems. What was added: • Duplicate payment requests are detected and blocked • Prevents double debit during retries or network interruptions • Proper 409 CONFLICT response handling • Custom exception flow for cleaner API behavior • Initial understanding of how concurrent duplicate requests can impact transactions Why this matters: In payment systems, retries and simultaneous requests are common. Without idempotency and concurrency safeguards, the same transaction can be processed multiple times. Current implementation works, but there is room to improve: Areas of improvement: • Return the original transaction response instead of only throwing duplicate error • Strengthen concurrent request handling with DB constraints / locking strategies • Add request payload validation for reused requestId • Introduce expiry/cleanup strategy for old idempotency keys • Improve observability with logs and audit trails Next step: I’ll be upgrading this into a more production-ready payment flow by improving concurrency safety and returning previous transaction state on retries. Built with: -Spring Boot -Spring Data JPA -H2 -REST APIs -Java Reliable backend systems are built by handling retries, race conditions, and edge cases not just successful requests. #Java #SpringBoot #BackendEngineering #Concurrency #Payments #SystemDesign #RESTAPI #SoftwareEngineering #LearningInPublic #Fintech

I’ve been working on strengthening my Java fundamentals, and I built a basic small banking system to put those concepts into practice.Not just watching tutorial. This is a console-based application, but the goal wasn’t just to “make it work”—I focused on writing cleaner and more structured code. What it currently supports:User login system,Deposit and withdrawal operations,Balance checking,Transaction history Simple menu-driven flow While building this, I spent time understanding how to properly use OOP concepts like encapsulation, abstraction, and interfaces. One change that really improved the code was moving all the logic out of the main method into a separate BankApp class. That made the program easier to read and extend. I also used an interface (Accountable) to define the core banking operations, which helped me think more in terms of design rather than just implementation. GitHub: https://lnkd.in/gyVTmny2 This is still a work in progress. Next, I’m planning to turn this into a proper backend application (possibly using Spring Boot) and add persistence. If you have suggestions or feedback, I’d genuinely appreciate it. #Java #BackendDevelopment #OOP #LearningInPublic

A subtle Spring behavior that causes real production issues: @Transactional propagation. Most people rely on the default propagation without thinking about transaction boundaries. Example: Method A → @Transactional (REQUIRED) calls Method B → @Transactional (REQUIRES_NEW) What actually happens? Method B runs in a NEW transaction. So even if Method A fails and rolls back, Method B can still commit ❌ Result: Partial data committed → inconsistent state Fix: • Use REQUIRED if operations must succeed or fail together • Use REQUIRES_NEW only when you intentionally need an independent transaction (e.g., audit/logging) • Define transaction boundaries clearly at the service layer Seen this during backend development while handling dependent operations. Lesson: Don’t rely on defaults — design your transaction boundaries consciously. #SpringBoot #Java #Transactions #Microservices #Backend #SoftwareEngineering

Another weekend side project. I built Yeu-Pay, a fintech REST API to explore the core mechanics of digital ledger systems and financial workflows. What I focused on : Authentication RSA-signed JWTs with Spring Security for stateless, verifiable identity Ledger design Clear modeling of Accounts, Transactions, Payments, and Invoices with enforced invariants Transaction integrity Atomic operations and consistency across related financial updates Card Provisioning Virtual card issuance with controlled balance and lifecycle states Persistence PostgreSQL + Flyway for explicit, versioned schema evolution Observability Actuator for visibility into system health and metrics Stack Java 21, Spring Boot, Spring Security, PostgreSQL, Docker Compose, Open to feedback, suggestions, or discussion. Repository: https://lnkd.in/dnhVA8cq #FinTech #BackendEngineering #SoftwareEngineering #Java #SpringBoot #SystemDesign #APIDesign #PostgreSQL #Docker #CloudNative

Day 6 — The Race Condition Bug Nobody talks about this in backend systems… Everything works perfectly… Until two users hit the same API at the same time. And suddenly: • Duplicate orders • Negative stock • Payment processed twice No errors. No crashes. Just silent data corruption. ⸻ 💥 The Problem Two threads access and modify shared data at the same time without proper control. Example: if (stock > 0) { stock–; } Looks correct, right? But under concurrency: Thread A reads stock = 1 Thread B reads stock = 1 Both decrement 👉 Final stock = -1 ⸻ ⚠️ Why it’s dangerous • Hard to reproduce (only happens under load) • Works fine in local testing • Fails silently in production • Direct impact on money and trust ⸻ ✅ The Fix Use proper concurrency control: • Optimistic locking (@Version) • Pessimistic locking (DB level) • Atomic operations • Synchronized blocks / locks • Idempotency for critical APIs ⸻ 🧠 Real lesson If your system handles payments, orders, or inventory… You’re already exposed to race conditions. It’s not “if” it will happen. It’s “when”. ⸻ 👇 Have you ever faced a race condition in production? What was your fix? ⸻ #Backend #Java #Microservices #SystemDesign #Concurrency #SpringBoot #CodingBugs #TechLeadership

🚀 Excited to share my progress on my Banking Application project! I started this project as a simple console-based application, and now I’ve successfully upgraded it into a REST API-based backend system using Spring Boot & JPA. 🔧 What I’ve implemented so far: 💳 Account Management Create Account Fetch All Accounts Get Account by Account Number 💰 Transactions Deposit Money Withdraw Money (with insufficient balance handling) Transfer Money between accounts (with transactional safety) 📊 Transaction History Built a separate Transaction module Used JPA relationships (@ManyToOne) Implemented clean DTO-based response Added automatic timestamp using @CreationTimestamp 🧠 Key Learnings: How REST APIs work in real backend systems Importance of DTOs over entities JPA relationships and database design Handling real-world scenarios like balance validation and transactions 🔜 What’s next? Adding Spring Security 🔐 Role-based authentication Making the project production-ready This journey from console app → REST API has been a great learning experience 🚀 #Java #SpringBoot #BackendDevelopment #JPA #RESTAPI #LearningInPublic #SoftwareDevelopment