GitHub/school-of-sre
1
0
Fork 0
mirror of https://github.com/linkedin/school-of-sre synced 2026-01-21 07:58:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

Deployed 944e497 with MkDocs version: 1.1.2

Browse Source
This commit is contained in:
github-actions
2022-09-25 13:50:48 +00:00
parent 04187e113c
commit a90a6a5cf0
11 changed files with 248 additions and 247 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
level102/system_design/scaling-beyond-the-datacenter/index.html
View File

@@ -2164,7 +2164,7 @@ the world, and would want to serve from the closest data center (DC) possible.</
<p>When an user sends a request, there are cases in which we might want to serve a specific user’s requests from a DC if we have multiple DCs, or a specific server inside a DC. We may also wish to serve all requests from a specific POP by a single data center. Sticky routing helps us do exactly that. It might be simply pinning all users to a specific DC or pinning specific users to specific servers. This is typically done from the POP, so that as soon as the user enters reaches our servers, we can route them to the nearest DC possible.</p>
<h2 id="geo-dns">Geo DNS</h2>
<p>When a user opens the application, the user can be directed to one of the multiple
globally distributed POPs. This can be done using <a href="https://jameshfisher.com/2017/02/08/how-does-geodns-work/">GeoDNS</a>, which simply put, gives out a different IP address(which are distributed geographically), depending on the location of the user making the DNS request. GeoDNS is the first step in distributing users to different locations - it is not 100% accurate, and typically makes use of IP address allotment information for guessing the location of the user. However, it works well enough for >90% of the users. After this, we can have a sticky routing service that assigns each user to a specific DC, which we can use to assign a DC to this user, and set a cookie. When the user next visits, the cookie can be read at the POP to decide which data center the user’s traffic must be directed to.</p>
globally distributed POPs. This can be done using <a href="https://jameshfisher.com/2017/02/08/how-does-geodns-work/">GeoDNS</a>, which simply put, gives out a different IP address(which are distributed geographically), depending on the location of the user making the DNS request. GeoDNS is the first step in distributing users to different locations - it is not 100% accurate, and typically makes use of IP address allotment information for guessing the location of the user. However, it works well enough for &gt;90% of the users. After this, we can have a sticky routing service that assigns each user to a specific DC, which we can use to assign a DC to this user, and set a cookie. When the user next visits, the cookie can be read at the POP to decide which data center the user’s traffic must be directed to.</p>
<p>Having multiple DCs and leveraging sticky routing has not only scaling benefits, but also adds to the resiliency of the service, albeit at the cost of additional complexity.</p>
<p>Let us consider another use case in which an user uploads a new profile picture for themselves. If we have multiple data centres or POPs which are not synced in real time - not all of them might have the newer picture. In such a case, it would make sense to tie that user to a specific DC/region until the update has propagated to all regions. Sticky routing would enable us to do this.</p>
<h2 id="references">References</h2>