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: