Recently I interviewed a Senior Engineer. Strong candidate. Kafka? ✅ Redis? ✅ Microservices? ✅ Distributed systems? ✅ Then I asked: "You're building the inventory service for a flash sale. Only 1 item left in stock." Two users hit “Buy Now” at the exact same millisecond. Both requests pass the “is available?” check. Both create an order. Both deduct stock. Now you’ve sold 2 items when only 1 existed. How do you guarantee you never oversell — even with concurrent requests, client retries, and partial failures? "Just use a database transaction." Doesn’t fully solve it if both requests read `stock = 1` before either writes, or if the response is lost and the client retries. "Check stock before deducting." What happens when both checks happen at the same time? "Use Redis DECR and reject if it goes negative." What happens if Redis is down, or the decrement succeeds but the order is never persisted? Your turn: How would you design this inventory reservation API so concurrent buyers and retries never oversell the last item? There’s a specific distributed-systems concept behind this. And you’ll encounter it everywhere inventory, tickets, seats, coupons, and limited resources are involved.

"Those who would trade essential safety for a little performance, deserve neither safety nor performance" - Ben Franklin. "Give me strict serializability or give me death" - @jorandirkgreef @TigerBeetleDB

Even if your database is infinitely fast and infinitely parallel you can’t hack your way around network round-trip time and contention, where multiple transactions force you to lock your hot rows. This is Amdahl’s law applied to transaction processing and it’s why even at just 10% contention, your throughput drops not by 10%, but 10X. @jorandirkgreef describes this fundamental flaw in the SQL transaction interface 👇 @TigerBeetleDB #OLTPforthenext30years