Merge pull request #167 from leebyoungsu/main

06-system-design-interview/02-back-of-the-envelope-estimation/brian/brian-ch02-back-of-the-envelope-estimation.md

@@ -0,0 +1,44 @@
+# Chapter 2: Back-of-the-envelope estimation
+
+## Power of two
+- The power of 2 = 2의 거듭 제곱
+- 2 to power of 10 = 2의 10승
+- A byte is a sequence of 8 bits.
+- 1 byte = 8 bits = 2 to power of 3.
+- The size of a char is a byte. (= 8 bits) 
+
+![1kb-1pb.png](pictures/1kb-1pb.png)
+
+## Integer
+![int.png](pictures/int.png)
+
+## Latency numbers
+![LatencyNumbers.png](pictures%2FLatencyNumbers.png)
+
+![LatencyNumbers2.png](pictures%2FLatencyNumbers2.png)
+
+## Availability numbers
+- SLA(Service Level Agreement): SLAs formalise the commitments made between service providers and customers within the Performance Management Framework. These agreements outline the expected levels of service, including specific metrics, response times, and potential consequences for not meeting the agreed-upon standards.
+- SLO(Service Level Objectives): Specific quantifiable goals set within the Performance Management Framework to define acceptable levels of service performance. These objectives ensure a more granular and focused approach to maintaining service reliability and quality.
+- KPI(Key Performance Indicator): Serves as the foundational metric within the Performance Manager Framework, offering a holistic view of organisational or operational success. They provide a broader perspective on overall performance and guide strategic decision-making.
+
+![SLA.png](pictures%2FSLA.png)
+
+## Ex: Estimate Twitter
+![twitterExample.png](pictures%2FtwitterExample.png)
+
+## Tips
+- Solving the problem is more important than obtaining results
+  - Rounding and Approximation. It is difficult to perform complicated math operations
+    during the interview. For example, what is the result of **“99987 / 9.1”?** There is no need to
+    spend valuable time to solve complicated math problems. Precision is not expected. Use
+    round numbers and approximation to your advantage. The division question can be
+    simplified as follows: **“100,000 / 10”**.
+  - Write down your assumptions. It is a good idea to write down your assumptions to be
+    referenced later.
+  -  Label your units. When you write down “5”, **does it mean 5 KB or 5 MB?** You might
+     confuse yourself with this. Write down the units because “5 MB” helps to remove
+     ambiguity.
+  - Commonly asked back-of-the-envelope estimations: **QPS, peak QPS, storage, cache,
+    number of servers, etc**. You can practice these calculations when preparing for an
+    interview. Practice makes perfect. 

06-system-design-interview/03-a-framework-for-system-design-interviews/brian/brian-ch03-a-framework-for-system-design-interviews.md

@@ -0,0 +1,68 @@
+# Chapter 3: A framework for system design interviews
+
+## A 4-step process for effective system design interview
+### Step 1 - Understand the problem and establish design scope
+- do not jump right in to give a solution
+- ask the right questions
+- write down your assumptions on the whiteboard or paper. You might need them later
+#### What kind of questions to ask?
+- What specific features are we going to build?
+- How many users does the product have?
+- How fast does the company anticipate to scale up? What are the anticipated scales in 3 months, 6 months, and a year?
+- What is the company’s technology stack? What existing services you might leverage to simplify the design?
+
+> DAU: Daily Active Users
+
+### Step 2 - Propose high-level design and get buy-in
+- Come up with an initial blueprint for the design. Ask for feedback. Treat your interviewer as a teammate and work together. Many good interviewers love to talk and get involved.
+- Draw box diagrams with key components on the whiteboard or paper. This might include clients (mobile/web), APIs, web servers, data stores, cache, CDN, message queue, etc.
+- Do back-of-the-envelope calculations to evaluate if your blueprint fits the scale constraints. Think out loud. Communicate with your interviewer if back-of-the-envelope is necessary before diving into it.
+
+> Go through a few concrete use cases
+
+### Step 3 - Design deep dive
+#### You and your interviewer should have already achieved the following objectives
+- Agreed on the overall goals and feature scope
+- Sketched out a high-level blueprint for the overall design
+- Obtained feedback from your interviewer on the high-level design
+- Had some initial ideas about areas to focus on in deep dive based on her feedback
+
+#### What will be the detail design?
+- could focus on high-level design
+- could focus on the bottlenecks and resource estimation
+- most cases will be to dig into details of some system components
+
+### Step 4 - Wrap up
+#### Follow-up questions or freedom to discuss other additional points
+- The interviewer might want you to identify the system bottlenecks and discuss potential improvements. Never say your design is perfect and nothing can be improved. There is always something to improve upon. This is a great opportunity to show your critical thinking and leave a good final impression.
+- It could be useful to give the interviewer a recap of your design. This is particularly important if you suggested a few solutions. Refreshing your interviewer’s memory can be helpful after a long session.
+- Error cases (server failure, network loss, etc.) are interesting to talk about.
+- Operation issues are worth mentioning. How do you monitor metrics and error logs? How to roll out the system?
+- How to handle the next scale curve is also an interesting topic. For example, if your current design supports 1 million users, what changes do you need to make to support 10 million users?
+- Propose other refinements you need if you had more time.
+
+#### Dos and Don’ts
+##### Dos
+- Always ask for clarification. Do not assume your assumption is correct.
+- Understand the requirements of the problem.
+- There is neither the right answer nor the best answer. A solution designed to solve the problems of a young startup is different from that of an established company with millions of users. Make sure you understand the requirements.
+- Let the interviewer know what you are thinking. Communicate with your interview.
+- Suggest multiple approaches if possible.
+- Once you agree with your interviewer on the blueprint, go into details on each component. Design the most critical components first.
+- Bounce ideas off the interviewer. A good interviewer works with you as a teammate.
+- Never give up.
+##### Don’ts
+- Don't be unprepared for typical interview questions.
+- Don’t jump into a solution without clarifying the requirements and assumptions.
+- Don’t go into too much detail on a single component in the beginning. Give the high-level design first then drills down.
+- If you get stuck, don't hesitate to ask for hints.
+- Again, communicate. Don't think in silence.
+- Don’t think your interview is done once you give the design. You are not done until your interviewer says you are done. Ask for feedback early and often.
+
+#### Time allocation on each step
+- Step 1 Understand the problem and establish design scope: 3 - 10 minutes
+- Step 2 Propose high-level design and get buy-in: 10 - 15 minutes
+- Step 3 Design deep dive: 10 - 25 minutes
+- Step 4 Wrap: 3 - 5 minutes
+
+