[3/3] System Design for Interviews and Beyond (Category Architecture)

As I wrapped up the course on System Design Interview, I wanted to talk about all the remaining parts that were not in the program. first-post and second post. The first post looked at requirements work, important architectural features, infrastructure, caching and queueing. The second post focused on data storage, system components interoperability, and data delivery quickly and reliably. In this final post, we will talk about protecting servers from customers and vice versa, as well as a few practical tasks.

11. How to protect servers from clients Here, the author talks about how an overload system usually looks like, what autoscaling is, how to apply load shedding and how to limit the number of requests using rate limiting. In general, we are talking about basic patterns for building reliable systems.

12. How to protect clients from servers Here it all began with a consideration of what types of clients are: synchronous and asynchronous. Next, the author analyzed how circuit breaker works and how it helps both clients and servers. Then there is the Fail Fast Principle, which in my view contradicts the concept of resiliency. Or is it my bias when I’ve seen too many examples of insecure code that have been justified by the fail fast approach:) The next principle of bulkhead is that I like to think of it myself in the context of the bulkheads on the Titanic, which were made shitty and didn't really protect against problems. Well, the final pattern is shuffle sharding, which looks really interesting in the context of the number of users who are affected by problems when nodes fail.

13. Practical challenges At the end of the course, the author offers to train in designing on fairly standard tasks:

• Classic url shortener
• Fraud detection system
• Authn and authz system
• Monitoring system

#Software #Architecture #DistributedSystems #SystemDesign #Engineering