Gapless sequential ids

[ItsRobbAllen]

At the most basic level, I am trying to implement event sourcing. For any stream of events, I need to ensure that each event of an aggregate root ID + version is perfectly sequential.

For example, if I have an aggregate root of Invoices/1763-A and am using version 1 of the aggregate root, I would like the IDs of the events to be Invoices/1763-A/1/events/1, Invoices/1763-A/1/events/2, Invoices/1763-A/1/events/3, etc.

If two systems try to write an event at the same time, my expectations is that both events would be written but first-come-first-numbered.

If I up the version, I'd expect the first event written would be Invoices/1763-A/2/events/1

I know Raven can assure sequential id's across clusters & whatnot, but they can have gaps if maybe a write failed or something. Is there anything built into Raven that would absolutely guarantee a sequential number or is this something I will need to look at handling externally?

If the latter, does anyone have any good ideas on how to ensure sequential numbers? It's critical that event 1 is followed by event 2 and there aren't gaps. If someone physically deletes an event, then that's on us and hopefully revisions will save us 😄

[georgiosd]

Hey @ItsRobbAllen - I'm curious - why is the sequential identifier important?

Don't you have to track the previous event or some sort of etag to verify correctness? If two events arrive out of order from the network from different users, presumably you need to pick one or essentially resolve it as a conflict, right?

[ayende]

This is a really complex problem.

On the face of it, fairly trivial, because RavenDB is transactional. You can have an operation that increments a value in one document and use that as the id for another.

The reason this is complex is what happens when you are running in distributed environment. Consider the case where you have two operations to add an event to the same document, on two different nodes at the same time.
What do you expect will happen then?

A better question, however, is why do you want this? What is the importance of absolute serial values?

[georgiosd]

Right, and in the bank example, the outcome is binary (can/cannot withdraw) - if it wasn't binary and the operation, if accumulated in the wrong order, would give a different result, that would also be a problem.

For example, multiplying after adding a value - can't think of a real scenario off the top of my head but sounds like that would get me into trouble if I didn't track what the previous state was.

[ayende]

There is a big cost for perfect consistency. In the real world, you almost never pay it.
Because business are built on high latency systems (a guy on a horse being the faster thing around for many years).
So there are a lot of compensating actions.

For example, if you buy a stock, you aren't actually buying it right now, it will be settled in a couple of days.
What actually happened is that you are submitting an order that would be accepted and processed later and the account shows the "data" as if it happened.
Makes for some interesting edge cases, see Robbinhood a year or so ago :-)

If you need perfect consistency, you pay the price for that (cluster wide transaction, single source of truth, etc).
The issue is when you want to have it and not have it at the same time.

[georgiosd]

Always fascinating to hang out in the RavenDB forums :)

[ItsRobbAllen]

Yes it is.

In my case, there are a TON of rules & checks that have to be run and the order of each event, much like PEMDAS in math, matters to the end result. Yet, like Oren indicates, it's not possible to have perfection so I'm just writing into the system ways to correct errors.

These should be few & far between as our application is not millions of operations per minute and we only have 1 cluster as it is. Still, better to be prepared.

[ayende]

FWIW, I wrote a blog post on the topic:
https://ayende.com/blog/199618-A/generating-sequential-numbers-in-a-distributed-manner?key=5c574503f5444912bf7f8a2922ecae21