System Design Basics: Mastering Idempotency for Technical Interviews
Stop duplicate API requests from breaking your data. Learn how to implement Idempotency Keys, handle network timeouts, and master the difference between idempotent and non-idempotent HTTP methods.
One of the hardest truths to accept when you move from writing code on your laptop to building large-scale systems is simply this: the network is not reliable.
When you write a function inside a single program, you can trust it. If you call updateDatabase(), it either works or it throws an error. It almost never “gets lost” on the way to the CPU.
But in the world of web applications and distributed systems, that certainty disappears.
Requests time out, servers crash unexpectedly, and Wi-Fi connections drop.
In this chaotic environment, the only way to ensure a request actually made it to the server is often to send it again.
But this introduces a dangerous new problem.
If we automatically retry a request, how do we make sure we don’t accidentally execute the same action twice?
How do we distinguish between a request that failed and a request that was successful but just slow to respond?
This is where one of the most critical concepts in system design comes in.
It is called Idempotency.
Understanding this concept is often the dividing line between a junior developer who builds features that work “most of the time,” and a senior engineer who builds systems that stay consistent even when the infrastructure is falling apart.
Let’s break down exactly what this term means and how you can use it to build bulletproof applications.
What Is Idempotency?
The word “Idempotency” comes from mathematics.
In math, an operation is idempotent if applying it multiple times does not change the result beyond the initial application. For example, look at the number 1.
If you multiply 1 x 1, you get 1.
If you multiply 1 x 1 x 1 x 1, you still get 1.
No matter how many times you do it, the result stays the same.
In computer science and system design, we adapt this definition slightly:
An operation is idempotent if performing it multiple times yields the same result as performing it exactly once.
Think of the “Call Elevator” button in your office building. When you press the button, the elevator system registers a request to come to your floor.
If you are impatient and press the button twenty times, the elevator doesn’t come twenty times. It doesn’t come faster.
The system simply ignores the extra presses because the request has already been registered.
That button is idempotent.
On the other hand, imagine you are sending a text message to a friend.
If you have a bad signal and hit “Send” three times, your friend might receive the exact same message three times.
That operation is not idempotent.
In system design, our goal is to make our critical operations, like payments, transferring files, or updating user profiles, behave like the elevator button, not the text message.