You've now got one publisher and two listeners.
Let's not try to emit another event by restarting the publisher so I can put in an hour s hit enter
and then I'm going to see two console logs one from each the listeners.
It looks like they both received that identical event.
The one with the sequence number of fifty two.
So we now have to these listeners.
They both receive the exact same piece of information.
And so presumably inside of any normal application if this was a real app they would both run some processing
on that event.
Now quick question for you.
If these truly are identical services just multiple copies or two instances of the same service would
sending them both the same exact events present an issue.
Well maybe let's think back to the earlier project we worked on inside this course.
I'm going to open up my code Etter very quickly back on that blog project directory OK.
So you might remember working on the blog project inside of here.
We allowed users to create posts and comments.
One big problem we ran into was making sure that we could make one single request and get all of our
posts and all of our comments all inside of one request to allow for that.
We created something called the query service and inside the query service we had some code that would
receive events.
We then processed all those events inside this handle event function.
We had some code inside there to handle post created comment created and comment updated.
But there's one event site that I want to focus on in great detail the comment created event.
So whenever we got an event of type comment created we took a look at the I.D. of that incoming event
or the post idea in this case we found the post that we had previously saved.
We then took a look at all the comments so we'd associated with it and then we pushed in a brand new
object representing that comment.
Now for a second let's just imagine that we were not storing these posts in memory.
Let's imagine instead that we are storing these posts inside of some kind of Mongo DB database or some
other similar kind of database so let's imagine what would happen if we ran this code right here or
something like that on two separate instances of this query service.
Well we would take the incoming event.
We would pull off the idea content and status and then we would add that in as a brand new comment inside
of our list of comments.
So what would happen if we essentially ran that line of code twice.
Well very simple we would end up with these same exact comment twice inside this comments array so very
frequently.
We do not want to allow an incoming event to go off to every copy of every service that we have.
So in other words if we've got multiple copies or multiple instances of the same service usually we
want to make sure that an incoming event is only going to go to one of them.
So either this first copy of it right here or this first copy of it over here.
So how can we do that.
Well there's something built into that string server that's going to make this very easy.
It's something called a queue group queue groups are something that we're going to be created inside
of a channel.
So at this point we have a channel called Ticket colon created inside this channel.
We are going to create a queue group we can have multiple queue groups associated with one channel so
inside of this channel we'll have our list of queue groups and we're going to give it some specific
name.
It could be anything we want to name it.
It just has to be some thing that kind of more or less makes sense to us.
Let's imagine that inside of here we create a queue group called simply my queue group we're then going
to make sure that our order service every instance of the order service creates a subscription and joins
that queue group like so now whenever we get an event coming into the ticket created channel not streaming
is going to take a look at all the different queue groups we have it's then going to more or less randomly
select one of the members out of every one of these queue groups and send the event to only one of those
members.
So in this case because both copies of our order service are members of my queue group that streaming
server is going to take the event and send it off to only this service or potentially only that service
right there now just to be clear we can still have other services that are not a member of this specific
group.
Let's imagine that at some point in the future maybe we have some other service some third service this
can have a subscription of its own that is just listening to General events coming out of ticket created.
It does not have to be a member of that queue group.
So now whenever we have an event come in that streaming server is going to take the event and it's going
to send off to either that service or that service because they are both members of that same queue
group but then any other service that is just listening to the overall channel will also receive a copy
of the event so we can really think of queue groups as limiting the number of times you send out an
event to just members of that queue group so how do we set up a Q Group.
Well fortunately it is really really easy.
Back inside my editor I got to go to our listener file.
Here's listener to us right here.
I'm going to find where we create our subscription and as a second argument to subscribe I'm going to
put in the name of the Q Group that I want to join.
So again this can be any name.
It just needs to be something that kind of makes sense to you and I.
So in this case maybe I will create a Q Group with a name of listener Q group maybe a better format
for this would be to name the Q Group after the type of service that is joining in.
So in our case we've got a Q Group right here that is only going to have the copies of the order service
joining.
So perhaps a better name would be something like orders service Q Group or something like that if we
wanted to take that approach then we would put in something like orders.
Service you group that would work as well.
The only requirement is that we make sure that every different service that tries to join into this
Q Group has that same string okay.
So let's now saved us all then go back over to my terminal and then back over here I'm going to once
again publish and events an LLC that it only got sent over to one of these two listeners and I can start
to send out multiple events and it looks like it's going to alternate between the two deciding that
hey first I going to send one to this copy of a listener and then over to this listener if you are not
seeing the same behavior if it looks like all the events are being sent to just one listener as opposed
to both.
That is totally fine as well.
Sometimes Natsumi server is going to decide to either do a round robin or in other cases just send them
all to one particular listener.
And there actually are some ways we can make sure that one listener doesn't always get sent all these
different events.
That's something we'll take a look at in just a moment.
Okay.
So in total this is creating a Q Group again a Q group is created to make sure that multiple instances
of the same service are not all going to receive the exact same event and this is going to make sure
that we don't try to do double triple or quadruple processing on the same in coming event all right.
So still a couple of things for us to learn so quick plans are here and I'll see you in just a minute.