In the last video we saw that we could read deliver all the events that have ever been emitted but that
was probably not the best strategy in the world.
So in this video we're gonna take a look at a very complimentary option to this idea of reading shivering
all events that have been emitted in the past.
The option we're going to take a look at is something called a durable subscription a durable subscription
is going to be created when we give an identifier to a subscription.
Let's first go and take a look at how we do that.
Back inside my editor I'm going to once again find this option stuff and I'll chain on another method
called right here of set.
Durable name.
This is how we create a durable subscription.
When we call set durable name we're gonna put in a string that's going to serve as the name or the identifier
for the subscription.
We're usually going to provide a name that kind of names or is the same name as this overall service.
So I inside of here would put in something like say order service or accounting service or whatever
we are trying to build out.
So what does a durable subscription actually do.
Well let's imagine we created our subscription with a name or I.D. of ABC one two three.
When we create that subscription Nats internally inside of the channel that we are subscribing to or
listening to is going to create a record listing all the different durable subscriptions that we have.
Then whenever we emit an event that's is going to record whether or not this subscription has received
and successfully process that event.
Let's imagine that we emit event right here.
Number one or sequence number one.
That's gonna go over to our service and our service might then acknowledge this event and say OK I've
successfully processed this as soon as that has been successfully processed NATS is going to store a
little record next to this terrible subscription and is going to say OK ABC 1 2 3 has processed
Event number one successfully.
So now let's imagine that for some reason our account service goes offline temporarily for some point
in time and maybe while it is off line we then emit events 2 and 3 so that service is no longer online
to receive this but internally NATS is going to keep a record of all the different events that ABC one
two three has missed out on.
So it's going to say OK number two right here.
ABC 1 2 3 has not processed this and 3.
ABC 1 2 3 has not processed this then.
Whenever our account service comes back online and reconnects with the exact same idea right there it
has to be the same NATS is gonna take a look at that subscription I.D. or the double name and it's going
to say okay for ABC once you three you have already processed Event number one but you have not processed
two and three so it will take two and throw it over and we'll take three and throw it over and then
once the account service processes those they will be marked as processed and processed so journal subscription
is really fantastic and making sure that our services never miss out an event and also make sure that
we do not erroneously reprocess events in the future which was kind of the downside of this whole set
deliver all available option.
Now quick question here.
Do we still need an option of set deliver all available if we are using set Durban name.
The answer is yes.
So setter or something set deliver all available is going to make sure that the very first time that
our subscription is created like let's say that we emit one and two before our services ever been created.
Let's imagine those are kind of sitting in history as kind of records hey we already emitted these things
at some point in the past.
If we then bring account service online for the very very first time and it has that option of set deliver
all available then for the first time only NATS is going to make sure that it takes all those events
from the past and deliver them to that service and add them as being delivered to ABC one two three
and that is only going to happen for the very first time we create this subscription.
So this set deliver all available is still a necessity because the very first time we bring the service
up online we're gonna get all the events that have been emitted in the past which is fantastic because
we can make sure that we don't miss out any data.
But then because we also have the double name here those events we had delivered in the past will be
marked as delivered.
So then whenever we restart the account service let's say we restart this for some reason or we bring
another subscription online.
Well we have already delivered one in two.
So even though we have set deliver all available that will be ignored on any restart.
So this option right here is really just used for the very first time we bring the durable name subscription
online.
All right.
Let's now save this file.
We're gonna go over to our terminal and test this out.
I want you to know that when we go and test this out even though we should only see all of our things
get the BRI deliver it just one time and then after that we should not get any redo livery because all
the previously admitted events have been marked as Red by this terrible subscription that is not quite
what we're going to see.
So let's just go take a look.
All right so back over here I'm going to restart this.
You'll notice that every single time I restarted I get all these different events re delivered and that
is very much contrary to what I just said was going to happen.
I just said that the very first time we start this thing up we're going to deliver all available.
We're then going to set up the durable subscription name of accounting service and then for any restart
because the subscription of accounting service has already gotten everything available it should not
get any reader livery.
So what's going on here.
Well this is a little bit of a gotcha.
Remember every single time that we restart this terminal window we are closing out our connection to
nets and we are reconnecting in that very short window where we close out the entire connection.
That's a saying oh that client disconnected.
That was the clients with this subscription or this journal subscription since they disconnected.
I guess they're probably never going to come back at any point time in the future so I'm going to wipe
out that history of that terrible name.
So for that just because that very very small disconnect window.
NASA's going to say let's just dump this history about that durable subscription.
They're probably not going to come back.
Right.
So that's obviously kind of a big downside to this approach.
Just because our service goes down for half a second we're going to throw out that journal subscription.
Well turns out that we can kind of use one other option we've already spoken about to solve this whole
issue.
So we're going to reintroduce our Q group inside of that stand subscribe to remember.
That's gonna be the second argument that's going to be a string and I'll put in my Q Group Name like
so.
So by adding in the Q Group right here it's going to make sure that even if we very temporarily disconnect
all clients are all subscriptions with this terrible name it will not dump the entire dribble subscription.
So just by adding on the Q group even if all of our different services inside this Q Group go down NASA's
going to persist that journal name subscription let's start saving this now.
I'll then go back to my terminal the very first time we start up.
We do get all of our events delivered but if now I restart this we're not going to get any re delivery
because again by adding in that Q Group along with the verbal name it makes sure that every time or
for some very brief period in time that everything goes off line the durable subscription does not get
completely dumped now at this point I just want to really highlight how the set deliver all available
this durable name in the Q group name.
These three options really all meshed together extremely well and they give us the exact behavior that
we are really really looking for.
So we just need to remember that for every subscription we create we are probably always going to use
such a lever all available that we can get all the events that's been emitted in the past we're going
to use separable name to make sure that we keep track of all the different events that have gone to
this subscription or the SKU group even if it goes off line for a little bit.
And then finally we're going to use this Q Group to make sure that we do not accidentally dumped the
durable name even if all of our services restart for a very brief period of time.
And to make sure that all these emitted events only go off to one instance of our services even if we
are running multiple instances so again.
Q Group Name Satya liver all available and set terrible name.
Very very tightly coupled options.
Now very last thing on go and restart the second listener when we restart the second one.
It's not tried to get a list of all previous events because all previous events have already been emitted
into this durable queue group and finally I should be able to publish another one.
Yep it still gets received over here.
All right.
So that's pretty much it.
These three options totally key deliver all of.
Terrible name and the Q Group let's take a pause right here and continue in just a moment.