<aside> ‼️ TL;DR: This is a collection of architectural information that is most commonly found in System Design Interviews (IC3+) but is extremely useful for more senior engineers. AKA, you should learn this regardless of the circumstances and it’s fun to know!
</aside>
The main purpose of creating this notion page is because of three reasons:
Feel free to add me on LinkedIn, follow me on GitHub, or email me at [email protected].
Without further ado, let’s begin!
In the context of interviews, the questions interviewers ask are intentionally vague (ie: Design Uber). It is your job to demystify the question by asking clarifying questions and build a viable and scalable solution with appropriate characteristics and components that you will learn here. The following are four categories that you need to hone in when interviewing and/or pragmatically coming up with an effective, scalable application:
FOUNDATIONAL KNOWLEDGE
In short, you need to be well-versed with all technologies, what they do, and their tradeoffs. System Design Interviews is entirely different from traditional coding interviews. Unlike LeetCode, there is no right or wrong answer but there are objectively wrong answers (ie: If you say a component does X and it actually does Y). You can’t write test cases for your architecture so having foundational knowledge is crucial.
SYSTEM CHARACTERISTICS
In life, there are tradeoffs with every choice. You can’t win ‘em all. It is your job to know and discuss the different tradeoffs when building systems. For instance, when making design decisions based on your objective, you would need to take in account for availability, consistency, latency, throughput, redundancy, etc… (these characteristics and more will be documented below).
TANGIBLE COMPONENTS
These are components that can be implemented in your system design to achieve your objective. Some of the components that fall into this category are load balancers, proxies, rate limiting, caches, etc… (these components and more will be documented below).
EXISTING TECHNOLOGIES
Existing products or services that you can actually use in a system(s) whether that’d be a component or a characteristic. Some examples of these can be amazon s3’s, nginx, redis, apache zookeeper, etc… (these technologies and more will be documented below). Many engineers overlook this category as you don’t really need it to build systems in the context of interviews but it will separate you from many other engineers and should be seen as a necessity regardless of your reason of reading this document.