- [Instructor] We successfully split out
all speakers' functionality,
and let's assume we handed over maintenance
to some other developers.
On a Friday evening, they decide
to roll out the new version of their service
that fixes just a small bug.
As a quick test, they reload the main page as I do now here,
and everything works perfectly.
A few hours later, you get a call that the website is down.
You try to open the page and you see that it doesn't load.
You restart it, and then it works again,
but now you're curious.
So, while clicking through the page,
you also click on this link that shows the speakers' list,
and you see that it doesn't load.
So you check out the most recent version
of the speakers-service, and I have it here already,
and there you look at the route
that is called for the speakers' list.
And there you see that
this return statement was commented out,
which means that this route would never return.
So, that's an easy fix, you restart that, and suddenly,
the website works again as expected.
So, how could this take down the whole website?
Let's look at what happened under the hood.
So, we have the conference-app,
and we have the speakers-service.
A user now tries to access the conference app
and there the list page, and this then calls
to the speakers-service.
This call now hangs and fails and, consequently,
the call out to the speakers-service will hang as well.
And, of course, consequently,
also the request by the user will stall.
Then another user comes around, and another, and many more.
All these pending requests first into the site
and out to the service and then inside the service
are stalling now for all users
and the respective node processes have
to keep track of all that connections.
Each open handle allocates memory and keeps hanging
in the no chase event loop that keeps filling up.
We should also not forget that users tend
to start to reload the page if it fails,
so the problem amplifies.
At some point the available resources are exhausted,
then all the calls that don't call
the faulty endpoint are effected.
This may again start at the speaker service,
and will finally then take the whole website down.
In a perfect world, all code is thoroughly tested,
and no one deploys on a Friday afternoon.
But the world isn't perfect, and we have to find a way
to make a service architecture fault tolerant
or resilient against such problems,
and this chapter is all about this very important topic.