Idempotency is easy until the second request is different • Hacker News Board

Re: Idempotency is easy until the second request is different

#241

Post by pdonis » Tue, May 12, 2026, 3:25 PM UTC

stickfigure wrote: post #237

pdonis wrote: post #231

Earlier quoted context omitted.

> Part of the problem here is that we're confusing how do you structure the API (replay? 409? something else?) with how we implement the API. It would seem to me that you would want "what happens if a second request comes in with the same idempotency key while the first is still in progress" to be part of the API, so clients would know what your server is going to do in that scenario.

Nobody cares. These are short lived transactions (generally milliseconds); collisions are a rare edge case; it's fine to block. One request succeeds, the other gets a dup error (or a replay). You could invent your own more sophisticated idempotency API but good luck finding someone that wants to implement it or use it. What real-world problem are you trying to solve?

> Nobody cares.

Meaning, clients don't care about the thing I asked about?

> What real-world problem are you trying to solve?

I'm trying to understand your answers to my questions. When there seems to me to be something missing, I ask about it.

Re: Idempotency is easy until the second request is different

#242

Post by stickfigure » Tue, May 12, 2026, 4:48 PM UTC

pdonis wrote: post #241

stickfigure wrote: post #237

Earlier quoted context omitted.

Nobody cares. These are short lived transactions (generally milliseconds); collisions are a rare edge case; it's fine to block. One request succeeds, the other gets a dup error (or a replay). You could invent your own more sophisticated idempotency API but good luck finding someone that wants to implement it or use it. What real-world problem are you trying to solve?

> Nobody cares. Meaning, clients don't care about the thing I asked about? > What real-world problem are you trying to solve? I'm trying to understand your answers to my questions. When there seems to me to be something missing, I ask about it.

Correct, clients don't care to be notified if some other short lived request is in flight.

Re: Idempotency is easy until the second request is different

#243

Post by girafffe_i » Wed, May 13, 2026, 6:21 AM UTC

I think you could condense this to a test plan (serious). I think if you come up with the cases in order these are solves problems and yes it’s part of your concurrency control, idempotency is part in parcel of distributed systems, otherwise you’re in your monolith with a wondrous central ACID interface.

I would argue sequencing is part of the hard part of idempotency, your business context would decide “when” to apply sequencing is good enough (recall monopoly “bank error collect $$$”).

Set and setting is also relevant, most places don’t deal with money or disastrous concurrency scenarios.

Now if you want to argue for a paradigm shift for why we shouldn’t be here to begin with and offer a way to get back to scalable centralized db system we’re all hears.

Re: Idempotency is easy until the second request is different

#244

Post by fud101 » Wed, May 13, 2026, 9:16 PM UTC

scott_w wrote: post #178

pdonis wrote: post #109

Earlier quoted context omitted.

What if the original request is still being processed when the retry comes in? That doesn't fall into either of your categories: the request isn't successful, but it hasn't failed either.

That’s because everyone here thinking about payments completely incorrectly. They’re not atomic and your server shouldn’t pretend they are. You need to store the payment state at each relevant step and process it asynchronously. If requests time out, you check the status of it using the key you store (with the processor) to see if it was even received. It’s not perfect, some processors will 500 while processing the p…

I'm not as smart as you folks but doesn't durable execution being a part of the solution help a lot in this respect?