Member-only story
Serverless API Essentials — Idempotency
A huge part of serverless API design is handling retries or accidental resubmits. Without it, data integrity goes out the window.
When I first got into cloud development, my team and I dove headfirst into all aspects of modern software design. One of the most fun discussions we had was around idempotency.
Not because of the academic discussions we’d have around it, but because none of us knew how to pronounce it. We’d all go around the room saying it different ways and nod our heads when someone pronounced it in a way that sounded right. None of us knew what it meant, but at least it was fun to say.
When we began trying to understand what it meant and how to implement it on our serverless apps, we started disagreeing.
Idempotency (pronounced eye-dem-POE-ten-see) at its core sounds like a simple aspect of software engineering. It refers to an operation that produces the same result when called multiple times.
But it’s not that simple. There are many sides to idempotency that I recently found out not many people agree on.
I ran polls on LinkedIn and Twitter last week with a tricky idempotency question to see what the community thought. The question I posed was:
What would you do for an idempotent endpoint when a duplicate request comes in while the original is still processing?
This in itself is a very targeted question. I didn’t ask about what idempotency was or about any of the major aspects of it. But I got opinions about everything. I felt like I set a trap for rabbits but caught bears, deer, rabbits, raccoons, and vultures.
Before we dive into the details around idempotency and what is wrong or not wrong, let’s take a look at the results. I received 325 responses with a pretty interesting distribution.
As you can see, we had a mixed bag of opinions on what to do in this scenario. This appears to be because of the ambiguity on what idempotency means in the industry. So let’s…
