System Design Framework.

Learn the most important thing and connect with the real system and problem rather than accumulating academin knowledge.

Dont be shallow and also dont go to a level of depth might be yellow flag.

Get the ambiguously defined high level problem and break it down to small piece of infrastructure and solve it.

No single right answer - navigate to the problem and define trade-offs and communicate your thinking.

System Design - Product design(Uber) and Infrastructure Design (Rate Limiter).

The interviewer is looking to asses some skills and knowledge throughout the interview go through the thought process and give them points to evaluate.

First target - complete the full design with the requirements.

Next work through all the basics and then discuss the depth of the knowledge in deep dives.

Main points - Problem Navigation, Solution Design, Technical Excellence, and Communication and Collaboration

Problem Navigation - Get to the main point of the problem. Example - Should not waste too much time in the user table and skip the important part.

Break down the problem in smaller pieces and get the most imp one and navigate through those pieces to the solutions. Follow the steps-

Explore the problem and gather requirements.

Get the uninteriesting vs the imp points. Dont get stuck in particular piece of problem and not able be able to move forward.

Dont fail to deliver a working system.

Maintain the delivery framework to be in track.

Solution design - Make small part of teh problem and interview wants to see how you solve each pieces. Imp to implement core concept.

The multi layered cache is an elegant solution to the massive read volume.

Most common pitfalls - Not enough understanding of core concepts. Ignore scaling and performance.

Spaghetti design - solution not well structured and difficult to understand.

Interviewer does not want memorised answer they will ask probing your reasoning, doubting your answer and tradeoffs.

Solid fundamentals and depth of knowledge will help.

Technical Excellence - To design great system you need to know best practices, well-recognized patterns, current technologies and how to apply them.

Understanding of key technologies.

They had strong command of Redis, Elastic Search and Inverted Indexes.

Most common pitfalls - Not knowing available technologies.

Antiquated approaches or being constrained by outdated hardware constraints.

No idea on how to apply in the problem.

Not recognizing the pattern an best practices.

Communication and Collboration - Dont be defensive on alternate approach.

Done be argumentative with feedback and dont get lost in the weeds and not be able to find the working solution with the interviewer.

One week timeline.

Get the fundamental core concept, key technology and common pattern and then handon and it will give 10x return.

Delivery Framework.

Structure your thoughts and focus on most imp parts.

Dont fail to design a working system and it will give a common like “time management” no need to fast its mainly focus on right thing.

System design interview structure.

Requirements - 5 mins.

Functional Requirements - User or client should be able to do feature.

Ask targetted question - does the system need to do X? What would happen if Y?

Get a prioritised list of core features.

The requirement should be strategic - the target is to make the system to complete the requirement. Top 3 design. Dont make a list of requirement it will create problem.

Non-Functional Requirements - System qualities. The questions like - The system should be able to.

Dont make it generic - The system should be low latency - every system feature. Make it specific and target to the system like the system should have low latency searc <500 ms. It identifies the part of the system that needs low latency and provides target.

Identify the top 3-5 NFR that can be considered.

CAP - System prioritize C or A. P is always there in distributed system.

Environment Cnstraint - Any consraints like the system should run in low battery, or limited storage or limited bandwidth.

Scalability - Get inn case there is any specific scaling in the system - does the system have bursty traffic at any specific day ?Does the system need to scale in read or write.

Latency - The time system will take to response to the user request. Low latency search in designing Yelp.

Durability - How imp is i that the data in the system is not lost? Social media can loss some data.

Security - How secure the system to be - data protection, access control compliance with regulations.

Fault Tolerance - Redundancy, Failover and Recovery Mechanism.

Compliance - Legal or regulatory things the system to meet - industry standard and data protection.

FCC SLEDS

Furry Cat Climbs Steep Ledges Every Day Securely.

Capacity Estimation - Perform the calculation in case it directly influence the design. In general cases its a distributed system. Tell the interviewer upfront that you would like to skip the estimation upfront and will do the math while designing.

Example - Design top K systems for trending topics in post. In that case the calculation impact in case of single topic to see the post then the min-heap and in case you need to get multiple instance then shard.

Get estimation understanding its better to design the tradeoffs. The estimation is called Fermi estimation. Estimation helps you in the quantitative part of the design.

How much storage the design need.

Communicate the thougt process, reasonable argument, ask relevant things.

The estimation is not mandatory but the estimation strenthens the quantitative backing.

Things like how long the data transfer take? How much memory will this feature require? In the cases make an educative guess. It highligh quick decision and good instincts a sign of exp.

Steps.

Determine what to estimate (quantity that is taking more load) - Break it down - Use what you know (apply fact you are confident) - Keep it simple (Precision is not the goal the ballpark is the goal) - Verify.

what to estimate - The journey to the estimate will improve the design. Where to apply estimates is a part of intuition want to demonstrate in the interview. Get the hint in case interviewer is asking to specific quantities. The best part is use the estimation in the crux of the system - any specific problem in the system.

Example in Twitter search the main part is the search indexes - understanding the contraints will help to decide what will be in memory and what on disk.

The crux of most of the design - Get the value of r and w troughput of the system and total storage of the system like memory and disk.

Break it down - Example twitter search and the search index storage size. Use dimensional analysis to create a mental graph of the quantities to develop. (Get more about it).

Get the start point - Tweets are 150 characters (storage/tweets) and Daily Active User O(250M) (users/day). In case we know tweets/users then we get the size.

(storage/tweets) * (tweets/users) * (user/day) we can get the storage/day.

Facts to know -

1 byte - 8 bits.

1 Thousand ≈ 1 KB ≈ 1000 bytes (1000^1 or 1024).

1 Million ≈ 1 MegaByte ≈ 1000000 bytes (1000^2 or 2^20 or 10^6)

1 Billion ≈ 1 GigaByte ≈ 1000^3 (10^9).

1 Trillion ≈ 1 TeraByte ≈ 1000^4 (10^12).

1 Quadrillion ≈ 1 Peta ≈ 1000^5 (10^15).

Stick with the factor of 1000 and get comfortable with the how much space would 5 million 1 kb records take - 510^610^3 = 5*10^9 = 5GB.

Latencies - Intuitions about latency.

Reading 1mb sequentially from memory - 0.25ms.

Reading 1mb sequentially from SSD - 1 ms - 4x memory.

Reading 1mb sequentially from spinning disk - 20 ms - 20xSSD.

Round trip network latency CA to Netherlands - 150 ms.

https://gist.github.com/jboner/2841832

SSDs are fast and affortable. Many severs work can be done by SSD.

Storage - The sample storage of media.

2 hour movie - 1GB.

Book of plain text - 1MB.

A high resolution photo - 1MB.

A Medium resolution image or site layout graphic - 100kb.

Business - The interviewer will give a figure for the system.

Active User of social network - O(1KB).

Hours of videos streamed on Netflix per day - O(100M).

Google searches per sec - O(100k).

Duration - Estimation should take max 3 min of the 35 min interview.

Dont continue estimating irrelevant task. Not to get stuck in basic math. Not to get the quantities wrong.

Good estimation muscle comes by estimating.

Candidate who proactively estimate seems more experienced and senior.

Entities - Approx 3 mins.

Get the entities to get the term and the data central. The entities get exchange by the API and the system will persist the entities. It mainly like putting the bullet list.

At this point dont design the data model and more entity and relationship will come at the time of design.

When the high level design is done then you will understand what stae needs to update on each request and get the list of relevant columns or fields for each entity.

Twitter example - entity - User, Tweet, Follow.

To identify the entity ask the actor of the system and are they overlapping. The noun or resource needed to fulfill functional requirement.

API System Interface - Approx 5 mins.

Which API protocol to use - REST, GraphQL (Client spefy what data they need avoiding over and under fetching. Used when diverse client with different data need), RPC(Remote Procedure Call - Action oriented protocol that acts faster than REST for service to service communication), Real Time use WebSocket.

API Design - The authentication is derived from the header and not the body and the url is plural tweets and not tweet (/v1/tweets).

Data Flow - 5 mins.

In data processing systems describe the high level processing of the system on the input to produce the output. Mention it when the system involve long flow of action then mention in the data flow.

The data flow define in list and use it in high level. Example - web crawler the picture will be - Fetch seed URL, Parse HTML, Extract URL, Store data and all.

High Level Design - 15 mins.

Comfortable in the entity, api of the system - proceed with the High Level to represent how the different component of the system interact with each other. Component of the system - server, db, cache.

Key technology idea will give more value in the component architecture.

Dont over think here - the target to satisfy the API and fulfill the requirement. Go with one by one API endpoint and build the design to satisfy each one.

Dont make it complex now - target to serve 100 customer with the functionality then layer to serve the non-functionality.

In the high level designw e can identify the places to add cache and message queue at this point callout or note it and move on.

Be loud and tlk the thought process and show the data flow and the state (db, cache, message queue) change with each request starting from the API request to the response.

The data movement and a sample return value and the column name to show the data state - cache what to store how long to store, db what to keep and rest api what to return - all this in short then in depth we can talk based on the interviewer interest.

When the data reaches the db start the entity and column name it will help to improve the design.

Dont waste time like User Table so add some basic and name number and dont continue anything that is not relevant.

Deep Dives.

The twitter example is inefficient to fetch user feed. In the deep dive we need to solve it. In deep dive meet the non-functional requirement, addressing edge case, identify issue and bottleneck, improve the design based on the interviewer.

The degree of the proactiveness in deep dive is the function of seniority.

Junior will expect the interviewer to point out the places system will break. More senior will find these places by themselves and leading the interview.

System need to scale >100 M DAU. The solution is arounf horizontal scaling, cache, db sharding - update the design. Feed need to fetch with low latency - fanout-on-read vs fanout-on-write and the cache.

The understanding of the flow and the return that will be low comes with experience and idea in the system. Cache return in single digit ms, a relational db in 30-50ms for simple queries and web server 10-20 ms when there is no heavy processing then the limit is within 100 ms window.

Senior engineer should talk here there are lot to talk but maintain balance and give the interviewer time to ask on your design. They need to judge you on target so get the input from the interviewer.

Add metrics and monitoring in the deep dive.

Functional.

The who? (Producer) - Who’s sending data?

The what? (Request) - What kind of data are they sending? What does it include?

The where? (Outcome) - What is the desired output or event?

Non - Functional.

Read or write-heavy, Need partition, Consistency( system data should be correct), Availability (system should be available), Durability or Latency.

The System design Interview is more like winning the interviewer heart. Go along with his doubts and question and make all his comments answered.

Make the discussion compact.

Numbers to know.

Understand modern hardware capabilities.

When to shard, when to cache, handle large object - the hardware idea.

Modern server has good computing power.

AWS EC2 M6i instance has 512 GiB of memory and 128 vCPUs.

EC2 is the virtual server instance.

Memory optimized instance X1e32xlarge provide 4tb RAM and U24tb1.meal reaches 24 TB of RAM. There are many system which initially needed distributed system not can run in single machine.

Catalog of the System Design Problem