The Sunday Commit
We spend a lot of time talking about how to make code run faster. We rarely talk about what happens when code runs twice.
Distributed systems are unreliable. Networks timeout. Servers crash. The natural response to a failure is to try again.
But in 2026, blindly retrying is dangerous.
If a user clicks "Pay Now" and the browser hangs, they click it again. If your API isn't designed to handle that, you just charged them twice.
This is where the concept of Idempotency comes in. It is the sophisticated art of doing nothing when asked to do something you've already done.
1. The hidden key in the header
Junior engineers handle payments by checking if a user exists. Senior engineers handle payments by checking if the request exists.
The pattern is simple but often overlooked. When a client (a frontend app or another service) makes a critical request, it should generate a unique ID, a UUID, and send it in the headers.
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
If you are building any system that moves money or deletes data, an idempotency key isn't a feature. It is a requirement.
2. The implementation logic
So how do you actually build this? You need a fast, ephemeral data store. Redis is the standard tool here.
The logic flow on your backend should look like this:
Intercept: Before running any business logic, grab the
Idempotency-Keyfrom the header.Check: Query Redis for this key.
If the key exists, it means we have already processed this. Stop immediately. Return the saved response payload from Redis. This mimics the original success without re-running the code.
Lock: If the key doesn't exist, create a temporary "processing" lock in Redis to prevent race conditions if two requests land at the exact same millisecond.
Execute: Run the actual heavy lifting (charge the credit card, update the database).
Save: Once finished, store the final response in Redis against that key and set an expiry (usually 24 hours).
This turns a dangerous "Write" operation into a safe check. You can retry the request fifty times, and the customer is only charged once.
3. THE CEREBRAL GYM: Solution & New Puzzle
Let's look at the solution to yesterday's problem and a new challenge for today.
Yesterday's solution (Rate Limiting) The problem was the "Fixed Window" flaw where a user could send double the allowed traffic at the edge of a minute boundary. The standard algorithm to solve this is the Token Bucket.
Imagine a bucket that holds 100 tokens.
Every time a request comes in, you take a token out.
If the bucket is empty, the request is rejected.
The magic: You refill the bucket at a constant rate (e.g., 1.6 tokens per second) rather than resetting it all at once. This smooths out the traffic and prevents burst attacks.
Today's puzzle (Database Concurrency) You are building a hotel booking site. You have one room left: Room 101.
Two users, Alice and Bob, click "Book Room" at the exact same millisecond. Your API receives both requests. Both threads check the database and see "Available." Both threads write "Booked."
Now you have two guests and one bed. Standard locking works, but it kills performance. What is the database pattern that uses a version number column to prevent this overwrite without locking the row during the read phase?
(Reply with the name of the pattern.)
4. THE PULSE: Book Recommendation
If you want to understand these distributed system problems deeply, I recommend "Designing Data-Intensive Applications" by Martin Kleppmann.
It is dense. It is academic. But it is the only book that explains exactly why your database lied to you about that transaction. It is required reading for anyone moving from Senior to Staff engineer.
5. THE LATENT SPACE
"Reliability is not about preventing failure. It is about containing it."
We cannot stop the network from timing out. We cannot stop the user from double-clicking. We can only design systems that don't collapse when those things happen.
Build for the retry.
See you tomorrow.
Harsh Kathiriya - Query & Context