Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idempotency

berkansasmaz.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Idempotency

#61

Post by karmakaze »

CSMastermind wrote: post #3

One of the things I think I did right in my career is working on payment and billing systems early on. It does teach you how to build at least semi-reliable software because people tend to get really mad when you screw with their money. It also is a good introduction to regulation and compliance. Idempotency was is one of the concepts you get taught on day one in that field (as kind of demonstrated by that being the…

Another good one is instant messaging. Both latency and reliability (exactly once delivery) are important.

Doing so using microservices will teach you a lot more (but may not be immediately applicable as it's not so favored).

Re: Idempotency

#62

Post by rmbyrro »

wayfinder wrote: post #25
jay-barronville wrote: post #14

Earlier quoted context omitted.

Interestingly, I didn’t have to be taught about idempotency early on in my career; I’m pretty sure I didn’t even know what that word meant. I’m a naturally curious person and I was always curious about the failure cases for the software I worked on—e.g., “What happens if this request is successful but times out before returning a response to the client?” I honestly assumed every programmer asked these types of questi…

The only reason I knew about idempotency is because growing up I was a little shit and I learned that you could break a LOT of electronics by getting it to do a second thing midway before finishing doing the first thing. If it had a screen and buttons, I would try to break it. So I started striving for highly reliable systems not because there are professional bad actors out there or spammers or to achieve high perfo…

> getting it to do a second thing midway before finishing doing the first thing

I'm not sure this is the kind of failure idempotency is design to tackle.

Idempotency tackles the issue of handling multiple requests for doing the same thing, isn't it?

Re: Idempotency

#64

Post by weaksauce »

rmbyrro wrote: post #62
wayfinder wrote: post #25

Earlier quoted context omitted.

The only reason I knew about idempotency is because growing up I was a little shit and I learned that you could break a LOT of electronics by getting it to do a second thing midway before finishing doing the first thing. If it had a screen and buttons, I would try to break it. So I started striving for highly reliable systems not because there are professional bad actors out there or spammers or to achieve high perfo…

> getting it to do a second thing midway before finishing doing the first thing I'm not sure this is the kind of failure idempotency is design to tackle. Idempotency tackles the issue of handling multiple requests for doing the same thing, isn't it?

> Idempotency tackles the issue of handling multiple requests for doing the same thing, isn't it?

yeah... there should be no extra side effect if you call something more than once on it with the same parameters. ie foo(x) is the same as foo(foo(x)) is the same as foo(foo(foo(x)))

or in networking GET x is the same as GET x followed by a GET x etc... the GET request doesn't (*shouldn't) change anything.

Re: Idempotency

#65

Post by wayfinder »

rmbyrro wrote: post #62
wayfinder wrote: post #25

Earlier quoted context omitted.

The only reason I knew about idempotency is because growing up I was a little shit and I learned that you could break a LOT of electronics by getting it to do a second thing midway before finishing doing the first thing. If it had a screen and buttons, I would try to break it. So I started striving for highly reliable systems not because there are professional bad actors out there or spammers or to achieve high perfo…

> getting it to do a second thing midway before finishing doing the first thing I'm not sure this is the kind of failure idempotency is design to tackle. Idempotency tackles the issue of handling multiple requests for doing the same thing, isn't it?

It gave me an intuitive understanding of state machines and idempotency is one solution to transitions.

If you start with State A and a call changes it to State B, what does running the call again do? A->B? But you’re already at B. Shit’s going to break. Redesign your system.

Re: Idempotency

#66

Post by rmbyrro »

wayfinder wrote: post #65
rmbyrro wrote: post #62

Earlier quoted context omitted.

> getting it to do a second thing midway before finishing doing the first thing I'm not sure this is the kind of failure idempotency is design to tackle. Idempotency tackles the issue of handling multiple requests for doing the same thing, isn't it?

It gave me an intuitive understanding of state machines and idempotency is one solution to transitions. If you start with State A and a call changes it to State B, what does running the call again do? A->B? But you’re already at B. Shit’s going to break. Redesign your system.

In this example, it seems the API should return some 4xx error.

If there's a process with two steps, moving from Step A to B requires the process to be at Step A and it's already at step B, it should return an error. At first glance, this doesn't seem the kind of problem that idempotency is supposed to prevent...

Re: Idempotency

#67

Post by wayfinder »

rmbyrro wrote: post #66
wayfinder wrote: post #65

Earlier quoted context omitted.

It gave me an intuitive understanding of state machines and idempotency is one solution to transitions. If you start with State A and a call changes it to State B, what does running the call again do? A->B? But you’re already at B. Shit’s going to break. Redesign your system.

In this example, it seems the API should return some 4xx error. If there's a process with two steps, moving from Step A to B requires the process to be at Step A and it's already at step B, it should return an error. At first glance, this doesn't seem the kind of problem that idempotency is supposed to prevent...

Instead of idempotency you can return a 4xx error too. You use idempotency because it’s logistically less complicated for the client.

Re: Idempotency

#68

Post by anonymous_sorry »

hschne wrote: post #6

Idempotency is one mathematical concept that's pretty useful for software engineers to understand. Heck, might be more useful than BigO. - Useful to know when you work with APIs (as the article outlines). - Very useful when working with background jobs. You're not gonna have a good time if those aren't idempotent. - Good to know for interviews. I was asked to explain idempotency a handful of times, weird as that is.

> Good to know for interviews. I was asked to explain idempotency a handful of times, weird as that is.

Do you now reply "I've been asked this before, so your question has no effect"?

Re: Idempotency

#69

Post by nokya »

"The PUT method is used to update a resource on the server. It is idempotent because sending the same request multiple times will result in the same resource state as if the request had only been sent once."

That's where I stopped reading.

Post reply on HN