Retry operations with duplicate event checking

EventStoreDB
#1

Hi,

I am trying to understand if EventStore would be a good solution for our use case.

We have many operations which make HTTP request, which are not necessarily idempotent, so need to implement safe guards on our side.
D
The thought is to use pre and post events around the HTTP request so that if an operatiom needs to be retried we can potentially skip the dangerous HTTP request.

Are we able to query previous events or otherwise have an indication that an event was already created.

#2

You can always query previous events. That said it is rather easy to
make operations idempotent with ES if you can set your expected
version + make a deterministic event id (ES handles it for you)

#3

Thanks Greg,

Looking a bit closer at the HTTP API, I couldn’t determine how I’d be able to query an event by its eventId, but I can see that the HTTP response returns a Location value which contains the URI to the event created.

#4

Also try this ...

curl -i -d@myevent.txt "http://127.0.0.1:2113/streams/newstream" -H
"Content-Type:application/json" -H "ES-EventType: SomeEvent" -H
"ES-EventId: C322E299-CB73-4B47-97C5-5054F920746E"

Now run it again.

Then look at the stream (note it only has one event). If you can get
the EventId to be deterministic then you have idempotency.

Cheers,

Greg

#5

Greg,

To be clear, my concern is not with the idempotency of Event Store, it is mimicking this behavior with a third-party API Service, which we don’t control.

Here is a happy path example:

  1. Receive initial message to perform HTTP operation

  2. Record the above event

  3. Perform external HTTP operation

  4. Record the above event

  5. Acknowledge message processed, removed from queue.

In the case that our system crashes/restarts before Step 5, the message will be retried. However since the external system is not idempotent, retries will generate a different response (HTTP 400, multiple e-mails, duplicate records, etc). So as the message is being processed, I’d want to know if an event from Step 4 exists before attempting to execute the happy path, which will allow the execution flow to skip directly to Step 5.

Within our use case, there is a strong case to be made for records retry attempts as separate events, in which case we wouldn’t want to leverage Event Store’s idempotency.

#6

just try reading the event.

of course there is still a race condition (send http request, die, restart)