Preventing Duplicate Transactions with Idempotency in APIs

💳 Pessimistic vs Optimistic Locking in Payment Systems — Which One Do You Choose? When building a high-scale payment application, handling concurrency correctly is not optional — it’s critical. Here’s how I think about it 👇 🔒 Pessimistic Locking Lock the data before making changes Guarantees consistency But… can lead to slower performance & deadlocks ⚡ Optimistic Locking Allow concurrent updates Validate before commit (using versioning) But… requires retry logic on conflicts 🚀 Real-world takeaway: 👉 For payments / wallet balance / inventory deduction→ Prefer Pessimistic Locking (safety first) 👉 For high-scale APIs / microservices / read-heavy systems→ Prefer Optimistic Locking (performance & scalability) 💡 What I’ve learned:In modern distributed systems, it's rarely about choosing one.The best systems use a hybrid approach based on use-case. ❓ What would you choose for a payment system?Safe & consistent OR fast & scalable? Let’s discuss 👇 #SystemDesign #BackendEngineering #Payments #Concurrency #Java #Microservices #TechArchitecture

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

Deep Dive into Error Handling & Request Validation in Payment Systems I recently worked on designing a robust error handling and validation mechanism for a payment integration system (Stripe-based), and documented the complete approach in this PDF: Here’s what I explored and implemented: 🔹 Structured Error Handling in Spring Boot Clear separation of 2xx (success), 4xx (client), and 5xx (server) responses Custom exception (StripeProviderException) with HTTP status, error code, and message Global exception handling using @RestControllerAdvice for clean and consistent responses 🔹 Standardized Error Codes 10xxx → Validation layer 20xxx → Processing layer 30xxx → External provider (Stripe) Helps quickly identify where the failure occurred in a distributed system 🔹 Validation First Approach Dedicated ValidationService to validate requests before business logic Fail-fast mechanism using custom exceptions 🔹 Handling External API (Stripe) Scenarios ✅ Success responses (2xx) → parsed and mapped ⚠️ Client/Server errors (4xx/5xx) → structured error handling ❌ No response (timeouts, network issues) → handled using retry-ready exception strategy 🔹 Dynamic Error Message Construction Handling inconsistent error formats from Stripe Creating meaningful messages using: type | message | code | param 🔹 Clean Service Design Separation of concerns between: HTTP layer Validation layer Business logic Exception handling This project helped me understand how real-world systems handle failures gracefully, especially in payment integrations where reliability is critical. GitHub Repository: https://lnkd.in/dBcjJwEF Always open to feedback and discussions! 🙌 #Java #Spring #SpringBoot #BackendDevelopment #ErrorHandling #SystemDesign #RestAPI #APIDesign #FullStackDeveloper #PaymentIntegration

🚨 Duplicate requests can break your system Real scenario: Payment API was called twice due to network retry 💥 Result: Double payment 😬 ✅ Solution: Implemented idempotency - Used unique request ID - Stored request state in DB 💡 Takeaway: APIs should be safe for retries. Especially for payments, orders, critical operations. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering  #Microservices #JPA #RESTAPI  #DeveloperLife #CareerGrowth

Great microservices are useless if the frontend team can't integrate with them. 📜🤝 In modern distributed systems, API Documentation isn't an afterthought—it's the contract. Here is a look at the OpenAPI 3.0 (Swagger) specification powering the Titan Core Banking ecosystem. Building the backend with Spring Boot is only part of the equation; ensuring that the iOS, Android, and Web clients can securely and predictably interact with the system is where true engineering discipline comes in. Key architectural highlights visible in this API contract: 🔒 Strict Security: Every critical endpoint is secured via Spring Security and JWT validation (as indicated by the authorization locks). 📦 Transactional Outbox Pattern: Notice the /api/admin/outbox/status endpoint. To ensure zero data loss between PostgreSQL and Apache Kafka during high-throughput peer-to-peer transfers, I implemented the Outbox pattern for guaranteed message delivery. 📄 Full-Suite Banking Domains: Covering everything from core P2P transfers and loan approvals to OTP generation and dynamic PDF statement rendering. Writing code that works is the baseline. Writing self-documenting, secure, and easily consumable APIs is the standard. 🦅 #APIDesign #Swagger #OpenAPI #SpringBoot #Microservices #BackendDeveloper #SystemArchitecture #SoftwareEngineering #Java

Why idempotency saved us from duplicate financial transactions 💳 One thing you learn quickly in real-time payment systems: Retries are not optional. Duplicates are dangerous. Recently ran into a scenario where a payment API was being retried due to intermittent network timeouts. From the client side, it looked simple: “Request failed → retry” But on the backend, that retry could have resulted in duplicate transactions — which is unacceptable in financial systems. 🔍 What actually happens under the hood: 1️⃣ Client sends payment request 2️⃣ Backend successfully processes the payment 3️⃣ Response times out due to network issues 4️⃣ Client retries the same request 5️⃣ Backend receives it again 👉 Now the system cannot tell: Is this a new payment or a retry of the same one? Without protection → 💥 duplicate charge -------- 💡 What is idempotency? Idempotency means: “No matter how many times you send the same request, the result remains the same.” --- 🛠️ What we implemented: • Introduced idempotency keys (unique per request) • Stored request state in Redis (PROCESSING / SUCCESS / FAILED) • Checked existing state before processing • Returned cached response for duplicate retries --- 🔁 How it works in practice: • First request → processed normally • Retry with same key → no reprocessing • Same response returned 👉 Client thinks retry succeeded 👉 System avoids duplicate transaction --- 🚀 Real impact: • Prevented duplicate financial transactions • Improved reliability during retries • Ensured consistent system behavior --- ⚠️ The hidden complexity: Idempotency is NOT just “check if request exists” It involves: • Handling partial failures (what if success but state not saved?) • Managing TTL (how long to keep keys?) • Handling concurrency (same request at same time) • Maintaining consistency across services --- 🧠 Key takeaway: In distributed systems: Failures are guaranteed Retries are inevitable. So your system must be: 👉 Safe to retry --- 📌 My biggest learning: The difference between a working system and a production-ready system is how it behaves when things go wrong. --- Curious — how are you handling idempotency in your systems? #SystemDesign #DistributedSystems #BackendEngineering #Payments #Microservices #Java #SpringBoot #TechInsights

Most developers think idempotency means "don't create duplicates." It's more than that. It's a guarantee. While building a payment system, I implemented two layers of idempotency: → Application layer: check if idempotencyKey already exists before processing → Database layer: unique constraint on idempotency_key column Why both? Because application logic can fail mid-request. Two retries can race each other. A network timeout can trigger a re-submit. If only the application layer exists, a race condition bypasses it. The DB constraint is your last line of defense. In payment systems, a missing idempotency layer doesn't cause bugs. It causes users to get charged twice. That's not a bug report. That's a legal problem. #Backend #Java #SpringBoot #SystemDesign #Payments

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

Why You Shouldn’t Ignore Rate Limiting in Production APIs 🚦 Your API works fine… until traffic spikes. 💥 Without rate limiting: • 🚨 One client can overwhelm your system • 🚨 Sudden traffic bursts cause outages • 🚨 Downstream services get overloaded ⸻ 📌 Common mistake: Relying only on infrastructure and ignoring application-level controls in services built with Spring Boot ⸻ ✅ What production systems do: • Apply rate limiting per user / API key • Return proper HTTP 429 Too Many Requests • Use token bucket / leaky bucket algorithms • Combine with API gateways and caching ⸻ 💡 Where this matters most: In fintech & banking systems: • Payment APIs • Login/auth endpoints • Public-facing services ⸻ Rate limiting isn’t just protection… it’s fair usage + system stability. ⸻ Build APIs that scale responsibly. ⸻ #java #springboot #backenddeveloper #microservices #api #ratelimiting #scalability #distributedsystems #systemdesign #fintech #bankingtech #cloudnative #singaporejobs #techcareers

Started building an offline-first UPI payment system in Java + Spring Boot. The core problem: digital payments fail when internet drops. Most solutions assume connectivity. This one doesn't. Day 1 focused on foundations- Account and Transaction models, initial settlement logic, REST APIs for testing, and H2 for rapid prototyping (PostgreSQL planned next for persistent storage and scale). But the more interesting work was defining the real engineering challenges: • How do you prevent the same payment from being processed twice when multiple relay devices forward it simultaneously? • How do you ensure an intercepted payment packet from yesterday cannot be replayed today? • How do you route payment data through untrusted devices without those devices being able to read it? None of that is implemented yet. But clear problem definition is exactly how Day 1 should end. #Java #SpringBoot #SystemDesign #FinTech #BuildInPublic #coding #springai