3 ms·

> Events are facts; they can (and should) have multiple receivers. Yet, the event producers shouldn’t assume getting a response. What this means is: There may

by mrkeen 4y ago

> Events are facts; they can (and should) have multiple receivers. Yet, the event producers shouldn’t assume getting a response. What this means is: There may be many consumers listening to payment events - a PaymentHistory service, a CustomerFraudDetection service, a Settlement service, a Bookkeeping service. If I publish the fact that {Customer x paid $3.40}, that event has been persisted, and is considered to have happened. What's to be done if something goes wrong downstream? From my point of view, I can't do any more. It is up to the downstream services to restore themselves to a good state. If I 'retry' that message, that's exactly the same as if the customer had paid twice.

aynyc 4y ago
One word: Idempotent.
- Izkata 4y ago
  Cool, now I can by hundreds of things that cost $3.40 and only pay once.
  - JustSomeNobody 4y ago
    > Cool, now I can by hundreds of things that cost $3.40 Why not? > and only pay once. Sounds like your rules engine is borked.
    - Izkata 4y ago
      > Sounds like your rules engine is borked. Well, that is what they suggested - it needs more work to prevent that situation.
- mrkeen 4y ago
  You may need a few more words than that. My preferred definition of idempotency is that your actions take you to a desired state - if it didn't work, try again, and hopefully you'll get to the desired state this time. The only time I've encountered an idempotency implementation in the wild, the team used the other interpretation of it, that is: the system will always respond the same for the same input. So if you try something and get an exception, they went through great lengths to ensure you would also get an exception the second time as well. Which do you prefer?
  - jonfw 4y ago
    The entire point of idempotency is not to always respond the same every single time, it's that the user can always expect the same response every single time. If the user receives a response it does not expect (or no response, etc.) than they don't want the same response on every retry, they still want the expected response In a perfect world, an idempotent app responds the same every time. But in a perfect world you don't really need idempotency.
  - aynyc 4y ago
    Your definition is generally inline with mine. The small exception is you can retry as many times as you can, once the desired state is reached, the result is the same after that no matter how many times you keep trying. Using the example given, I (as producer) can retry the message however many times, the response I get should be the same. Implementation detail usually involves some kind of ID so downstream consumers know that they have process the said ID. I do not believe if there is an exception, then future retry produce exception as well. But perhaps I misread your example.
phkahler 4y ago
>> If I 'retry' that message, that's exactly the same as if the customer had paid twice. Transactions (events) and messages are not the same thing. There should be no problem resending a GUID identified (or maybe a timestamped) transaction.
- deleted 4y ago
  [deleted]
- mrkeen 4y ago
  > Transactions (events) and messages are not the same thing Correct. I 'publish events', I do not 'send messages'. > There should be no problem resending a GUID identified (or maybe a timestamped) transaction. Let's say that I do want to roll my own resending (instead of publishing once). Do I record that a GUID is processed before or after I respond to it?
  - lucasyvas 4y ago
    Respond meaning by sending a receipt back the to the original sender? Before. Because then the sender can assume it never arrived if it never receives a response and can try again. If the receiver has already processed/recorded it, it goes through the motions again, but in an idempotent way that doesn't break anything by performing the action twice (or more). Eventually, the sender will get the response that it doesn't need to try again and it will reach resolution. This is an extension of the two generals problem and can be totally resolved by using an idempotent design. However, you can never guarantee a resolution is reached on any given attempt, and that is by design. My personal favorite approach is not using timestamps. The sender attaches a unique GUID, and the receiver records that GUID along with the processed event record. If the receiver sees it 100 times, it doesn't matter. It will do nothing the next 99 times, and tell the sender that it performed the task even without actually repeating it. Eventually the sender will record that and stop asking.
    - mrkeen 4y ago
      My followup question seems to have arrived out of order with respect to your suggestion. >> Do I record that a GUID is processed before or after I respond to it? > My personal favorite approach is ... the receiver records that GUID along with the processed event record. Well, does the receiver record that it has handled that GUID before or after it attempts to handle it?
deleted 4y ago
[deleted]

by mrkeen 4y ago

aynyc 4y ago

One word: Idempotent.

Izkata 4y ago
Cool, now I can by hundreds of things that cost $3.40 and only pay once.
- JustSomeNobody 4y ago
  > Cool, now I can by hundreds of things that cost $3.40 Why not? > and only pay once. Sounds like your rules engine is borked.
  - Izkata 4y ago
    > Sounds like your rules engine is borked. Well, that is what they suggested - it needs more work to prevent that situation.
mrkeen 4y ago
You may need a few more words than that. My preferred definition of idempotency is that your actions take you to a desired state - if it didn't work, try again, and hopefully you'll get to the desired state this time. The only time I've encountered an idempotency implementation in the wild, the team used the other interpretation of it, that is: the system will always respond the same for the same input. So if you try something and get an exception, they went through great lengths to ensure you would also get an exception the second time as well. Which do you prefer?
- jonfw 4y ago
  The entire point of idempotency is not to always respond the same every single time, it's that the user can always expect the same response every single time. If the user receives a response it does not expect (or no response, etc.) than they don't want the same response on every retry, they still want the expected response In a perfect world, an idempotent app responds the same every time. But in a perfect world you don't really need idempotency.
- aynyc 4y ago
  Your definition is generally inline with mine. The small exception is you can retry as many times as you can, once the desired state is reached, the result is the same after that no matter how many times you keep trying. Using the example given, I (as producer) can retry the message however many times, the response I get should be the same. Implementation detail usually involves some kind of ID so downstream consumers know that they have process the said ID. I do not believe if there is an exception, then future retry produce exception as well. But perhaps I misread your example.

phkahler 4y ago

>> If I 'retry' that message, that's exactly the same as if the customer had paid twice. Transactions (events) and messages are not the same thing. There should be no problem resending a GUID identified (or maybe a timestamped) transaction.

deleted 4y ago
[deleted]
mrkeen 4y ago
> Transactions (events) and messages are not the same thing Correct. I 'publish events', I do not 'send messages'. > There should be no problem resending a GUID identified (or maybe a timestamped) transaction. Let's say that I do want to roll my own resending (instead of publishing once). Do I record that a GUID is processed before or after I respond to it?
- lucasyvas 4y ago
  Respond meaning by sending a receipt back the to the original sender? Before. Because then the sender can assume it never arrived if it never receives a response and can try again. If the receiver has already processed/recorded it, it goes through the motions again, but in an idempotent way that doesn't break anything by performing the action twice (or more). Eventually, the sender will get the response that it doesn't need to try again and it will reach resolution. This is an extension of the two generals problem and can be totally resolved by using an idempotent design. However, you can never guarantee a resolution is reached on any given attempt, and that is by design. My personal favorite approach is not using timestamps. The sender attaches a unique GUID, and the receiver records that GUID along with the processed event record. If the receiver sees it 100 times, it doesn't matter. It will do nothing the next 99 times, and tell the sender that it performed the task even without actually repeating it. Eventually the sender will record that and stop asking.
  - mrkeen 4y ago
    My followup question seems to have arrived out of order with respect to your suggestion. >> Do I record that a GUID is processed before or after I respond to it? > My personal favorite approach is ... the receiver records that GUID along with the processed event record. Well, does the receiver record that it has handled that GUID before or after it attempts to handle it?

deleted 4y ago

[deleted]