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

Idempotence now prevents pain later

ericlathrop.com

Post reply on HN
Print view View original

91–100 of 133 posts

Re: Idempotence now prevents pain later

#91

Post by k_sze »

I think an even higher level of thinking is to think thoroughly about the ways the system can fail. Idempotence just happens to be _one_ way of dealing with certain failure modes.

As an engineer, the more exposure and experience you get, the more insight you have about the ways things can fail. Identifying the ways something can fail is the really important step here. You can’t know what failsafe to implement if you don’t actually know how something can fail. But once you do know how something can fail, implementing a proper solution is easy a lot of the time, even if you are not explicitly aware of the concept of idempotence, for instance. Only in some tricky Byzantine edge cases do you need very specific, well-established, track-proven algorithmic solutions.

Re: Idempotence now prevents pain later

#92

Post by cortesoft »

pbreit wrote: post #31
brsg wrote: post #20

Idempotency is a pretty critical concept in system design, and I think most developers have run into issues related to it even if they aren't directly familiar with the term. To give another simple example as the OP - Suppose you have a product that relies on time series data. For demo purposes you might create a curated data set to present to clients, but the presenter doesn't want to show data from 2019 as the "mos…

The idempotency I’ve seen is usually an unnecessary extra complexity.

I am very curious what environment you work in where this is the case. I can't think of any work I have done where idempotency is not important

Re: Idempotence now prevents pain later

#93

Post by harlanji »

gregmac wrote: post #88

I have worked on lots of software that involves event-driven actions, and apply this concept throughout. "Need to send a notification email when x condition becomes true". Naive way: during processing, check the condition and call the SendEmail() function. Idempotent way: Run a query that finds all x conditions, join to a list of notifications based on email+id+time, and only if there's no entry, send the notificatio…

Apparently if you want spare cash, little books of this stuff could sell for $5-10. Just became aware myself, setting up to write again.

That’s to say, this comment probably just saved or made me money. I’ve some hands on but clearly not as much as you exhibit. Thanks.

Target audience: Sr SE, reporting to next level up and perhaps offering tradesoffs, or advising peers or reports working on those systems and need a refresher to give a complete answer to a question.

Re: Idempotence now prevents pain later

#94

Post by randomsearch »

gregmac wrote: post #88

I have worked on lots of software that involves event-driven actions, and apply this concept throughout. "Need to send a notification email when x condition becomes true". Naive way: during processing, check the condition and call the SendEmail() function. Idempotent way: Run a query that finds all x conditions, join to a list of notifications based on email+id+time, and only if there's no entry, send the notificatio…

well today i just learned something very important, thanks!

How can I find more wisdom like this?

Re: Idempotence now prevents pain later

#95

Post by glic3rinu »

Izkata wrote: post #72
jchw wrote: post #36

This is good but not enough. You also need to be sure that you can’t charge twice if the job runs twice. When you do that same query twice, you will get the same list of users. This could be done by exploiting database consistency rules, like using strongly isolated transactions. One simple more general approach is to use an idempotence token. You could, say, have a table with a uniqueness constraint, and generate ID…

> This is good but not enough. You also need to be sure that you can’t charge twice if the job runs twice. When you do that same query twice, you will get the same list of users. That's handled by the extra condition in step 1 of the altered rules: > which haven't been charged the fee this month.

OP is talking about concurrent execution of the task without serialization on the database (serializable isolation is almost never the default). Which results in 2 concurrent queries getting the same list of customers to charge.

Re: Idempotence now prevents pain later

#96

Post by glic3rinu »

jbluepolarbear wrote: post #74
jchw wrote: post #36

This is good but not enough. You also need to be sure that you can’t charge twice if the job runs twice. When you do that same query twice, you will get the same list of users. This could be done by exploiting database consistency rules, like using strongly isolated transactions. One simple more general approach is to use an idempotence token. You could, say, have a table with a uniqueness constraint, and generate ID…

Have you used a iterator as the token? I had data that could be accessed and mutated from multiple different sources at the same time. With just a token and blocking the data caused race condition (cross server race conditions/deadlocks are just the worst). I solved this by giving an iterator with every read and a write required the same iterator back with the changes. If 2 servers try to write at the same time the f…

vector clocks?

Re: Idempotence now prevents pain later

#97

Post by yosamino »

gregmac wrote: post #88

I have worked on lots of software that involves event-driven actions, and apply this concept throughout. "Need to send a notification email when x condition becomes true". Naive way: during processing, check the condition and call the SendEmail() function. Idempotent way: Run a query that finds all x conditions, join to a list of notifications based on email+id+time, and only if there's no entry, send the notificatio…

Is what you are describing not what they call "event-sourcing" ?

Just keep a log of all the events that have already happened (crucial - I have seen "event logs" that were more like "request logs") and to find out the current state of the system - if the notification or report has has been sent - by examining this log.

The lists you are describing kind of sound like an event log of sorts.

It seems to me that this distinction between primary and secondary approach is not really neccessary.

Re: Idempotence now prevents pain later

#98

Post by pjc50 »

harlanji wrote: post #93
gregmac wrote: post #88

I have worked on lots of software that involves event-driven actions, and apply this concept throughout. "Need to send a notification email when x condition becomes true". Naive way: during processing, check the condition and call the SendEmail() function. Idempotent way: Run a query that finds all x conditions, join to a list of notifications based on email+id+time, and only if there's no entry, send the notificatio…

Apparently if you want spare cash, little books of this stuff could sell for $5-10. Just became aware myself, setting up to write again. That’s to say, this comment probably just saved or made me money. I’ve some hands on but clearly not as much as you exhibit. Thanks. Target audience: Sr SE, reporting to next level up and perhaps offering tradesoffs, or advising peers or reports working on those systems and need a r…

How would you market those? It's been a very long time since I bought a book on software.

Re: Idempotence now prevents pain later

#100

Post by hvidgaard »

yosamino wrote: post #97
gregmac wrote: post #88

I have worked on lots of software that involves event-driven actions, and apply this concept throughout. "Need to send a notification email when x condition becomes true". Naive way: during processing, check the condition and call the SendEmail() function. Idempotent way: Run a query that finds all x conditions, join to a list of notifications based on email+id+time, and only if there's no entry, send the notificatio…

Is what you are describing not what they call "event-sourcing" ? Just keep a log of all the events that have already happened (crucial - I have seen "event logs" that were more like "request logs") and to find out the current state of the system - if the notification or report has has been sent - by examining this log. The lists you are describing kind of sound like an event log of sorts. It seems to me that this dis…

The more structured way to do this is a CQRS framework with Event Sourcing as the underlying data store model. With that you create specialized readmodels that react to events and you can query them for the exact thing you need to know. Once you do something based on that query it will result in new events that update the readmodel. It's a powerful way of designing a system.
Post reply on HN