This is the second piece of the System Design series. Today we are going to take a look at CDN, Web Tear architectures, Async Data Processing and other topics.
This is where we stop in the previous article:
Let’s go on and improve this System!
CDN
CDN stands for Content Delivery Network. We can think of it as geographically sparsed Caches for a Web Server. This is a useful thing for delivering static content like images, audio tracks or even JavaScript and HTML. Below you can find a picture describing the main principle of CDN.
As you may find above, there are multiple CDNs all over the globe and a single Server (that contains the original static content). When a user fetches some content item for the first time, it gets saved in the CDN for some time. Then, the next requests are processed by the CDN and a user doesn’t need to wait too long again. I.e., this is like a Cache.
Let’s take a look at one more example showcasing this cache nature of CDN.
This is the description of the Pic. 3:
- User 1 requests “index.html”.
- As User 1 is the first user who requests this file, the System fetches it from the Web Server, saves in CDN for some time and sends it back to the requester.
- User 2 requests the same “index.html”. And this user is in the same region as User 1.
- As this file is already saved in CDN, the file is quickly delivered to the requester.
There are some points you need to consider using CDN:
- CDN is an expensive thing. The balance between cost and profit should be found.
- It may be rather complex to find the right expiry policy and expiry timeout.
- When CN is broken, content should stay available.
Stateful Web Tier
Stateful Web Tier stores some data between requests. In most cases, it means storing session data. Maybe you remember “$__SESSION” from PHP? 😅
This is how we may represent a stateful Web Tier:
As you may already know, stateful architecture is not a good solution. This is hardly supportable and error-prone.
Stateless Web Tier
In this architecture, there is no inter-requests data in a Web Tier. Such a System is robust and scalable. In a case when some state data is required, it should be moved out of a Web Tier. As a good example — to a separate NoSQL storage. Below you can find an appropriate diagram describing it.
Now our System can easily scale Web Tier and Shared State Storage independently. It is a good approach for fast-growing systems or systems with accidental traffic growth.
Data Centers
In the previous article, we discussed how Load Balancer may help us balance the traffic. In this section, we are going to add to our System a geoDNS routing. This allows balancing the traffic considering a user’s geolocation. Below you can see it on a diagram.
There are some gotchas:
- GeoDNS routing is a complex thing from a tech perspective.
- Data sync between multiple regions may be a real pain.
- Deployment to several Data Centers is not trivial stuff.
But if your System operates across multiple regions, it is a worthy approach. Moreover, the complexity is mitigated if you are using services like AWS.
Async Tasks
Just imagine a situation when your System has the feature of processing a huge amount of goods selling statistics and generating profit predictions for the nearest future. A rather heavy task, isn’t it? How would you design this feature?
A good idea here is to use a Message Queue. It is an element that allows async communications between a Producer (who requests data processing) and Consumer (who processes data and builds predictions). Let’s take a look at the diagram.
We are not going to deep dive into this approach. There are some cons and pros that you can find on the web for your specific problem.
Intermediate Summary
This is the final System Diagram until now. We have GetDNS, Data Centers, Async Data Processing Microservice, CDN and Shared State Storage. Looks very good! This System is able to scale partially and gradually, depending on the type of requests and evolution vector.
This was the second part of the “Gradual Improvement” paper. In the next article, we are going to take a look at the System Metrics and DB scaling approaches.
To be continued…
