With both the custom event bus we put together and Nat streaming that we're using now.
One thing that was really critical was to make sure that we could handle a service going offline for
some period of time while the service is offline.
We're not going to be able to process any events that are being emitted.
So when this thing might come back online we need to make sure that we can somehow give it a list of
all the events it has missed through and figure out how to do that with Nat streaming.
In this video we're going to first take a look at a kind of naive way of doing this and then eventually
how we can combine a couple of different options together to come up with a ideal solution whenever
we emit or publish an event in that streaming.
It's gonna be stored internally inside of this channel.
So we might emit something like account deposits 70 NASA's going to try to deliver that to our service
and simultaneously store a copy of that event as well we might then also emit this deposit of 40 dollars
that will be emitted to the account service and simultaneously save to that history so all these events
we ever emit and save a channel will be automatically saved when we then create a subscription at some
point in time the future we can customize the subscription and tell it to somehow grab or get this list
of events that have been emitted at some point in the past.
So let's take a look at exactly how we do that and to get started going to first go back over my terminal
and I'm going to close down the second copy of the listener.
Things worked just a little bit differently.
If we are running these options with a q group so I'm going to remove the Q Group very temporarily as
we take a look at how we can re deliver these events that we missed in the past so I'll make sure that
I only have one listener running.
I'll then go over to my editor.
I'm going to find that argument we put in B side of here of order service Q Group and delete it.
Right now OK so now to somehow tell Nat so we want to re deliver or get some messages that have already
been delivered in the past.
We're going to add in another subscription option to this list of options to first get started by doing
a command click on subscription options that will take me into the type definition file and I scheduled
to scroll down just a little bit and see an interface right here of subscription options.
If you do not see that interface then you can go back to where we just command click to and do a command
click on the interface right here of subscription options so this has the listing of all the different
option methods that are available to us we can scroll down a little bit and we're going to see that
there are some options like set start at sequence set start time that start with last received and set
deliver all available.
So these are some different methods so we can call to customize which events we get replayed or reset
that have been emitted in the past possibly while this service was offline let's try out set deliver
all available.
So if we add in this option to our subscription object that whenever our subscription gets created NATS
is going to try to send over all the events that we missed while or before the subscription was ever
created or while it's been down.
So back inside my listener file I'm going to find the options object and I'm going to chain on after
doing a little bit of cleanup here just to make this more legible set deliver all available like so
and then going to save this look back over and will see that the still a running listener right here
has restarted and has been sent all of the different events that we have emitted over time.
If I tried to restart this with an R S when this subscription is recreated again on this next startup
it gets sent all the events again and so I can restart as many times as I want and every single time
I get emitted the big list of events.
So clearly this is kind of handy for making sure that if a service ever goes down we can somehow get
a list of all the events that have been emitted in the past.
The only downside here is well every single time we start up a new listener because maybe we are restarting
our service or maybe we are scaling it up or whatever it is we are going to be reading livered our big
list of events after we've been running our application for possibly weeks months or years.
There might be thousands or hundreds of thousands or even millions of different events saved up so it's
not super feasible in the long term to just say that with every subscription give me all the different
events that have ever been emitted.
It could work but it's not super feasible.
So we usually do not use this set deliver all available option by itself.
Instead we're going to use this option along with one other option that's going to give us some more
desirable behavior.
Let's take a pause right here.
We'll take a look at that other option in the next video.