(upbeat music)
- Welcome back to the Azure Cosmos DB Essential series.
My name is Mustafa,
I am the Portfolio PMM for Azure Cosmos DB,
and this season we're joined by Mark Brown,
a PM on the Azure Cosmos DB product team.
This season, we want to take use cases a step further
and dive into some of the architectures
customers are using to build lightweight applications.
In the last three episodes,
we covered real time telemetry,
a product catalog and an order processing solution.
In this episode, we wanna focus more broadly
on how we can take full advantage
of distributed NoSQL by globally distributing our apps.
- Azure Cosmos DB is a distributed NoSQL database.
In order to provide the advantages of high availability
that comes with being a distributed database,
we keep four copies of user's data
across four replicas within a replica-set in each region.
And we provide replication to every Azure region worldwide.
This does two things.
First, it reduces the latency of reads for users
by bringing the data closer to them.
The less distance data must travel,
the faster it can get there
and that provides greater performance.
The second thing is it provides for greater availability.
Data that is replicated in multiple regions
can survive events where a region may become unavailable,
such as when a network connectivity is lost
or a natural disaster occurs.
So data replication increases availability
and improves read performance
by bringing data closer to users.
Users can also enjoy greater write performance
when enabling a feature called multi-region writes.
This effectively allows every regional read replica
to accept rights, making those faster now, too.
Data written into any region is then merged and replicated
to every other configured region.
- So how about we dive into the architecture
and start to sort through some of the details.
Let's start with Azure Traffic Manager.
What does Azure Traffic Manager do?
- Azure Traffic Manager is a DNS load balancer.
It routes traffic from end users to regional endpoints
into your applications deployed within those regions.
Traffic Manager routes your traffic
based upon the routing methods used.
You can choose from many, including priority,
round-robin, weighted, geographic, performance and others.
If we were to go with the performance routing method,
we could for instance, route users to the endpoint
that offers the lowest network latency.
But there are some instances where we may not want that
and there are other configurations, such as geographic,
which will route users to specific endpoints
based upon the geographic location
where those requests originate.
This is most often used
when there are data sovereignty restrictions in place
where traffic cannot leave a specific country.
Now, if we were pointing to three endpoints, say A, B and C,
what we're going to do is have an instance of Cosmos DB
in each of those regions.
- In practice, we may have two, four or N regions, right?
But for the sake of the example,
it makes sense to focus on three.
So walk us through how this configuration
is gonna actually improve availability?
- Right. So let's say region A goes down.
If we are using the performance routing method,
when region A becomes unavailable,
traffic will be routed to either the B or C regions,
depending on which of those is faster.
So all requests will go to those two regions
onto then the corresponding Cosmos DB instance
in those regions.
When region A comes back online,
requests will be routed back to it
and things will return to normal.
- So I can see how something like Traffic Manager
can help with availability
for both the user and the application's front end.
Are there other ways in which this type
of multi-region deployment
where you have both the front end and the database
in each region can help with greater availability?
- Yeah, definitely.
There are in fact, multiple places where connectivity
or availability might be lost.
You could lose connectivity within a region
between an application's front end and the database,
or Cosmos DB itself may lose availability
within a single region.
In scenarios like that,
the front end in the region where that occurs
can simply redirect its request to the next closest region
where there's a database deployed.
The SDK client in Cosmos DB
maintains a list of network latencies between regions.
So when it fails over to another region,
it knows out of those regions
you have configured for the account,
which is the next closest region to retry the request on.
Best of all, this happens automatically and quite quickly.
The only thing users may notice
is their application requests
are taking slightly longer now,
and this is due to the application's front end
in that region now making requests in another region
to the database.
And as before, once that region is restored,
the SDK client will reconnect
and everything will go back to the way it was before.
- Thanks so much, Mark.
And thanks everyone for joining.
that wraps up the last episode of season three.
We hope you learned something
and look forward to seeing you next time.
(upbeat music)