Scribd
Upload
14 views

Subtitle (6)

Uploaded by

yirga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
14 views

Subtitle (6)

Uploaded by

yirga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

We've looked a lot at what happens and

how do we introduce resilience when we have individual service


instances failing. We're trying to figure out which service instance we should talk
to at a particular
point in time, and is it taking too long?
All of these types of things. But sometimes what we're
going to see is that an entire service may
become unavailable, and we need to do
something about it. Or there may be an entire
communication mechanism that becomes unavailable. Resource unavailability
is going to be a common problem
that we'll see, and this is just
inherent when we are dealing with these
distributed systems, with all issues related to networks and host resources and
other things
that are happening. What do we do about
these things? Another important pattern is something is how do we
do the architecture? How do we build the architecture
in a way that allows us to handle these issues
with entire services failing? Now we're going to
talk a little bit about what we can do in
these particular cases. Let's imagine, again, we have our flight service, and one
of the things that
we need to do is we're going to actually book a flight. Let's imagine that we
have a booking service. Once we use the flight service, now maybe this architecture
doesn't make the most sense, but I want you to bear with
me here for this example. We could also call
this a trip service. We could call this
something else, but for the moment, just imagine that we've called our entry point
to this
thing, the flight service. We get a request in to
go and book a flight, and we want it
between two airports. The first thing the flight
service does is it goes and looks up the
departure options, it presents them
to this end user, and the end user
selects one of them, and now the flight service is supposed to go in to
create a booking. Let's imagine that
we're trying to go and access this booking service
but there's some problem, some reason why we can't access any instance of the
booking service at all. What do we do about this? This is where we have
something called a fallback. The fallback pattern
is telling us that we need to have ways of falling back when we can't access a
particular
service anymore. A fallback is an
alternate way of accomplishing the task
on behalf of over here. Now, there's a number of
fallbacks that we can have. One fallback might be maybe we have multiple providers
that
can do the booking for us, so maybe we have a
primary booking service. You can imagine this
being like travel agents. If our first travel agent is unavailable for whatever
their systems have gone down, we could fall over to an
alternate booking service. Maybe they have a totally different API for
working with them, so in order to
fall back to them, we have to switch over
to a different API, and maybe it has
different capabilities. This would be one way of
falling back is to use a completely alternate service that could accomplish the
task. Another way of falling back
might be to go and say, "Well, we can't handle
that booking right now, so we will put all these
bookings into a queue, and at some later point in time when this booking
service comes back online, it can go and process all of the missing bookings that
have filled up this
queue over here. Everything that we couldn't do immediately on your behalf, we will
go and do
in the future." Another way of falling
back is basically to queue these things up for later processing and
just to tell the client, "Great, we've received
your request, we are going to now
process it in the future." We could design our
API so that when the client gets a result back
of trying to book a flight, that the result could be
either, yes, we've booked it, or here is the future
confirmation code that you can check
on the status of your booking and check if it's officially been booked or not at
some point in time. One way is we can have
completely alternate services and code-pass. Another way is we can queue things up
for
later processing and we just communicate
to the client that your result isn't
quite ready yet. We could also potentially have other communication
mechanisms. Maybe we're using
HTDP or something, but maybe there's some other
communication mechanism that we can use to get
to that booking service. That is yet another
alternate code path. Fallbacks, and using
a fallback pattern, is all about having an
alternate code path, a way of getting things done that can satisfy the
request in some way. Basically what we're trying
to do is we're trying to shield the real
client over here, whoever is submitting
the booking request, from knowledge of
what's happening. We don't want them
to see our errors. If we can find some other
way of satisfying them, even if it isn't exactly
what they wanted, but we can shield them from
that error because we sit between them and the services
that are being used, that's something that
we would want to do, and that's what the
fallback pattern gives us. We're basically at
our client over here finding an alternate
way of getting the job done.

You might also like