CoffeeBee

Recently I interviewed a Senior Engineer. Strong candidate. Kafka? ✅ Redis? ✅ Microservices? ✅ Distributed systems? ✅ Then I asked: "Your wallet service holds a user’s balance. Current balance: $50." The user triggers two concurrent “Send $40” requests (or one request times out and the client retries). Both requests read the balance: Balance: $50 ✅ Both deduct $40 and succeed. Now the balance is negative. How do you guarantee the balance never goes below zero — even with concurrent requests, retries, and network failures? "Just use a database transaction." Doesn’t fully solve if two requests read the same balance before either writes, or if the response is lost and the client retries the whole operation. "Check the balance before deducting." What happens when two requests check the balance at exactly the same time? "Store the balance in Redis and use DECRBY." What happens if Redis is unavailable, or the decrement succeeds but the transaction record is never written? Your turn: How would you design this wallet deduction API so concurrent requests and retries never overdraft the balance? There’s a specific distributed-systems concept behind this. And you’ll encounter it everywhere balances, credits, inventory, and limited resources are involved.