Well time for the moment of truth time to see if all this version stuff is going to fix our concurrency
issues.
So I've opened up this little test script once again as a reminder this test script is going to first
try to create a post or me not a post but a ticket at a price of five and then going to update it to
10 and then update it to 15.
So we're going to expect to see all tickets eventually at a price of 15.
I've also increased the number of requests that are made in parallel to 400.
Now technically remember it's 400 times three.
So really.
Twelve hundred requests more or less in parallel again with no J s not technically in parallel truly
but more or less running at the same time so beyond that.
Also remember I've got two terminal windows open here.
They're both connected directly to Mongo DB on the right hand side is my orders database on the one
on the left hand side.
My orders database and on the right hand side is tickets so I'm going to start up that script.
I've got my scaffold window open over here and we're going to see some pretty interesting output beyond
seeing a tremendous number of messages saying that we have processed some number events.
We're actually going to start to see a couple of errors in there as well.
We're going to expect to see an error any time some event is being processed out of order so the errors
are going to come from this line of code right here or.
Well really this line of code right here.
So we're going to try to find some very specific version of a ticket if we are processing events out
of order.
This query is not going to find anything.
We won't have a ticket and we'll end up throwing an error.
Now keep in mind that when we throw the error after five seconds of not calling it message not right
here and that streaming server is going to automatically read this batch or ream at the event that we
fail to process.
And so after those five seconds in theory we will have processed the second event or the first updates.
And so when we tried to tackle this third event or the second update now we should go to find a ticket
with the correct version.
So how we're going to actually see that reflected inside of our scaffold logs we're gonna see a tremendous
amount of output.
Very quickly then a brief pause and then after about two or three seconds we're going to then see another
small little batch of log statement stuff saying oh we have now processed this event that's we're gonna
see in total.
Well enough talking let's actually run this.
I'm gonna do a node index just to run the test scripts.
I'll then go back over to my scaffold logs are gonna see all this output and it's going to stop really
quickly
okay.
There's the stop and now we're gonna wait a couple of like half a second and then boom.
Those are all the backfilled events.
These are all the events that fail to be processed because they were processed out of order.
And if I even scroll back up we're gonna see some number of logs or errors inside of here as well.
So these say ticket not found that is an instance of where we tried to process some event out of order
that I can keep scrolling up and I'll see that yep there definitely are some number of events that were
processed out of order or at least we attempted to now.
The last little moment of truth here we're going to run a query on both our databases and we're going
to expect to find the exact same number of tickets with the same price inside of both them.
So on the orders database.
Well let's do tickets first because this one should always be correct.
I'll do a DV tickets fines and I'm really going to expect to see that every ticket has a price exactly
a 15 so I find that all 400 tickets that I created.
Yep.
They end up at the price of 15.
So we're going to do the same query over here on the orders database and we're going to expect to see
exactly 400 as well which would indicate that all of our data is truly in sync.
So I'll do a DV tickets find the price of 15 at the length and there we go.
That's it.
So it looks like this version tracking stuff really does solve a lot of its versioning issue so it's
going to keep track of the aversion of all these different records we're going to use that implicitly
to nationally order our different events.
This really is fantastic.
It's a great solution and make sure that even if we start to receive art events out of order for some
crazy reason we're always going to bounce the out of order event process the one that we should be processing
and then eventually reissue this one and apply it to our database so this really is a great solution
but I think it'd be a little bit better if we maybe had a couple of tests as well.
Let's take a pause right here.
There's one or two other quick things I want to discuss and we'll continue in just a minute.