In this video we're gonna take a look at a couple of different ways of making sure the expiration service
waits about the 15 months or so before emitting that expiration complete event.
The first thing we want to do is really just kind of picture that service in isolation.
The idea here is order created comes in and then we're gonna have some mechanism inside of here to await
that 15 minutes or so and then eventually emit some event of expiration complete.
Now I keep talking about waiting 15 minutes and all that stuff just as a very quick reminder if we think
back to when we actually create an order and where we assign that timer if we go back to our order service
take a look at routes and then new T S inside of here.
You'll recall that our mechanism for actually tracking when the order expires is a timestamp.
So that is the time at some points in the future when this order is going to expire.
So when I talk about waiting 15 minutes or something like that it's really not so much waiting for 15
minutes so much as it is waiting for this timestamp to go from being in the future into the past.
In other words when it is this time indicated by this time stamp right here that's where we want to
emit this expiration complete Yvette.
Having said that as we're discussing the service I'm really just going to keep saying oh yeah we want
to wait 15 minutes or so.
There's not technically we are waiting 15 minutes inside the service.
It is really technically at some future point time that is indicated inside of this event.
We want to admit that event of expiration completes.
So that little disclaimer out of the way what are the ways that we can actually implement this.
Well the first one that we can take a look at really simple super basic.
We could say this is totally an option but there is a big downside to it we could say that whenever
we see this event come in we could just use something like set time out so we can have some set time
out function we tell it to wait 15 minutes.
Now that's not actually valid right there we cannot give a set time out a string of 15 minutes but you
get the idea we could provide some number of milliseconds to wait and after that number of milliseconds
we can have some code inside of here to publish the expiration complete event.
And this definitely is an option but it's not super viable.
The reason that it's not a great option is that set time out stores a timer in memory.
So if our expiration service were to ever restart for any reason whatsoever then all the timers that
we have running at that point time are going to be lost and we're going to completely forget about the
fact that well we have to publish in the expiration complete event in some remaining amount of time
so this will be super simple in nature but a very clear downside to it so it's another option.
The second option we have available to us would be to just set up a listener for order created and every
single time we see this event come in we could check to see if the expires at time inside that event
is in the past.
If it is in the past then we could emit the expiration complete event and if it's not the past if that
expiration time is still at some point in the future we can just not ask the incoming message if we
do not act this incoming event or number acknowledge it.
That means that NATS is going to automatically rediscover this thing five seconds in the future.
And so we could just rely upon that constant rediscovery and every single time we could just check the
expires at time and whenever it's in the past we can say okay time to actually act this event finally
and publish our own and this is also without a doubt a viable option.
We could definitely put something like this together but there is a pretty big downside to this one
way of tracking events that fail constantly inside of application is to track the number of times that
they get re delivered.
So in other words we might have other events that we are having trouble processing inside of our app
and for logging purposes we might want to track how many times they get rediscovered and then maybe
after we have tried to process them say five six seven eight nine 10 times we might then through some
kind of critical alert to our engineers and say hey there's some event that we just plain can't process.
And so if we are relying upon this kind of reading every mechanism for both logging purposes and for
some core business logic life is going gonna get really confusing really quickly.
So although this could be a viable option I'd say that Ed just doesn't quite feel right and it's gonna
make some things complicated and the line that's option number two is going to option number three option
number three this would be a fantastic option.
Unfortunately it is not supported by Nat string server.
So down here I've got in this diagram message broker.
So this is to say some other implementation of a event plus let's really be really precise here with
our naming this would be not Nats there are other event bus implementations that are going to support
this kind of feature.
Let's first talk about what the future is.
So in this approach approach number three we could say that whenever we receive order it created will
then receive that inside of expiration service and without any delay whatsoever like the instant we
receive this event we could publish our own event of expiration comp. But we could attach to that event
when we publish it.
We could tell our event bus to not publish this thing for another 15 minutes so in this case we'd be
relying upon our event bus to wait 15 minutes before actually sending out this event to the rest of
the world.
Now unfortunately Napster server just doesn't support this this idea here of some kind of delayed message
is referred to as a scheduled message or a scheduled event so you will see other event plus implementations
that support this.
But again not support by Nat string server and this would be a pretty great little feature if we had
ability to do this because if we had the ability to do this we wouldn't even need at the expiration
service we could actually just have our order service itself published an event that says oh hey remind
me in 15 minutes that I need to expire this order.
So in this scenario if we had access to this kind of future well the order service could just say Hey
remind me in 15 minutes to do this thing and we would be all set.
Good to go but for the fifth time now not supported by Natsumi server.
So not an option.
All right.
So that's option number three onto option before and as usual as you can guess this is what we're gonna
do inside of our application so inside of our expiration service we're going to make use of a little
library called Bull J.S. This is a javascript library that allows us to essentially setup Long Live
timers of sorts or essentially give ourselves notifications.
It's really a very general purpose framework for allowing us to store some amount of data do some processing
on it and possibly have some scheduled aspect to it as well so inside of our expiration service we're
going to use bolt J.S. and we're going to tell it remind us in 15 minutes to do some amount of work
we're going to pass that command into bulges and Bill James is going to store this little reminder inside
of a readies instance if you're not familiar is read as is essentially an in memory database is very
commonly used for tasks exactly like this right here the inside of readies bull is going to store a
list of jobs or things that are scheduled to be done at some point in time after those 15 minutes elapse
bull J.S. is then going to get a little reminder from readies that it needs to do something and ball
in turn is going to turn back around to us and say hey 15 minutes have elapsed it's time for you to
do whatever it is you wanted to do.
And so for us we're going to just publishing events of expiration complete note that's it.
That's what we're going to be using inside of our app.
So for our expiration service really what we're going to be doing is focusing ourselves on learning
a little bit more about this bull J.S. library and about how to set up a copy of readies inside of our
communities cluster as well which will be.
Trust me super easy and straightforward so that's it.
That's a We're gonna go with.
And I hope that the explanation of those other three options were Andy as well.
Let's get started on this expiration service in the next video.