In the last video we saw that we can get into some really big trouble if we ever successfully save a
record to the database and then fail to emit an event describing that record.
We just saved so we would not update this other database or this other service over here and a user
would see some really strange data inside of our app.
So how can we solve this.
Well luckily there's a somewhat straightforward approach to this pretty straightforward and it's going
to work vast majority the time to make sure that we don't run into any really big issues.
So here's the idea though as in the diagram we were just looking at in the code that we currently have.
We have seen that whenever we save record to the database we're then going to immediately emit an event
or publish it over to our event bus to solve this whole issue rather than emitting an event over to
the event bus.
We're going to instead save that event into our database so we're going to still take some record in
this case a transaction or whatever a ticket whatever it is save it into our database and we're going
to simultaneously take the event that we want to emit and rather than immediate we're gonna save it
into some kind of events collection inside of our database as well.
Then along with that event we're going to record some kind of flag on whether the event has actually
been published.
When he first say this thing into the database no the event has not yet been published.
So you would say no it has not been set then inside of some separate process or some separate piece
of code something outside of our root handler.
We can then have some code that is watching this event call it collection and it can take note of any
time we save a new event into it.
Any time we save a new event into this event collection this separate piece of code can then extract
that event essentially pull it out of that collection and publish it off to nets once it successfully
gets published.
We can then update this scent flag over too.
Yes.
This event has been published for this kind of two stage approach is going to go a long way to solving
this entire issue if there's ever some issue connecting to our database.
Well then we will fail to save this transaction and the event.
And so we will not have any data integrity issues if is down or if our connection to Nats is down for
some crazy reason we can still save the ticket to the database or save the transaction to the database
save the event and then hopefully at some future point time when our Nats connection comes back up this
separate piece of code or process or whatever else can still pull this event out and publish it often
that's this approach really makes sure that we're not going to run into this issue where we save a record
and fail to publish some data around it.
There is one other thing to imagine.
However there might be some kind of crazy possibility where we successfully save this transaction in
and then maybe fail to save that event.
Maybe fail to save the event because there is some kind of database constraint or something like that.
So we really need to make sure that whenever we save a transaction though if that gets saved we have
to make sure that the event gets successfully saved as well.
And if saving either these things fail then we need to make sure that we undo all the changes that we
have made to the database.
In other words if we successfully save the transaction but not the event we need to make sure sure we
roll back saving the transaction.
And if we save the transaction or something save the event but not the transaction we need to make sure
we roll back saving the event as well.
So to do something like this a lot of databases have something like this already built in.
Even Mongo DB does.
This is the idea something called a database transaction.
Now let me pause right here and say that we have the word transaction on this diagram twice and these
are two very different transactions.
So inside of this database this transactions collection is talking about a user depositing some money
or something like that.
That is some very application specific behavior.
A lot of databases on the other hand so this is the other use of the word transaction.
A lot of databases implement a feature called a transaction and a database transaction is something
that allows us to say there is a set of changes that we want to make to our database.
And if any of these changes fail do not make any of the changes so we can wrap up saving this record
and saving the event inside of a database transaction.
And if saving either of these things fails the database will automatically roll back all these changes
so a database transaction will ensure that we always save the record and the event along with it successfully
or both them will fail.
So again that's how we're going to solve this issue.
Now you might recall earlier on inside this course I said that I wanted to build this application as
realistically and production great as possible but that we were going to cut one or two corners so this
entire system right here of saving an event into the database and publishing it later on.
And this entire idea of a database transaction.
This is where I'm kind of drawing the line for the course.
We are not going to implement this inside our application just because it adds in a pretty good amount
of complexity.
And to be honest with you I don't really anticipate us to ever really have to deal with an issue around
saving a record to the database and then possibly not successfully saving some person and publishing
some information over to nets.
So I just don't really think we are going to experience this issue inside of application and I don't
really expect that we will ever even be able to effectively test that or test this realistically as
well.
We could definitely write some kind of automated test to make sure that this thing works expect as expected.
But I just don't really expect us to be able to test it in any realistic scenario.
So we are not going to implement this inside this application.
But I just wanted you to know that this is a concern and it's something that you might want to write
some code to handle.
Again we would save it or deal with this issue by saving the record an event at the same time having
a separate process to pull events out at events collection publish them often that's and we would probably
want to also make sure that we wrap up saving the record and event inside of some transaction as well.
OK.
So that's that as usual.
Quick pause right here.
Continue in just a minute.