시스템 디자인 인터뷰 공부: 템플릿, 시간 분배 (feat. Grokking the Systems Design Pattern)

 

 

간단하게 목차를 쭉 훑고 모든 문제들에서 기본적으로 언급해야 되는 것들과 실제 인터뷰할 때 시간 분배를 어떻게 해야 되는지 찾고 정리해보았다.

 

 

 

SDI 준비하면서 읽고 있는 책

 

 

시스템 디자인 인터뷰 공부를 위해 내가 읽고 있는 책은, 이미 시스템 디자인 인터뷰 책으로 유명한 Grokking the Systems Design Pattern이라는 책이다.

책 구성은 총 15개의 인터뷰 문제와 기본적인 시스템 디자인 개념들을 마지막에 인덱스로 정리 되어있다

 

 

 

 

 

SDI 템플릿 & 마음가짐 & 시간분배

 

기본적으로 숙지해야 할 내용들

 

 

 

책에 나와있는 목차에서 기본적으로 꼭 들어간 목록들을 엑셀로 정리해봤다.

 

 

다시 정리해보자면,

 

---

1. Spec identification (functional & non-functional)
2. Capacity Estimation
3. API Design
4. High Level Systems
5. Database Schema
6. Component Design
7. Scalability
8. Fault tolerance

---

 

SDI 인터뷰시 마음가짐

 

✔️ Relax and apply the template

✔️ Ask until everything is clear

 

✔️ Build up a story

 

✔️ Ask and confirm

 

✔️ Trade-offs 생각하기

이 디자인을 선택하면 그것에 대한 alternative solution이 뭔지에 대해 짧게 얘기하기

 

 

 

 

SDI 시간 분배

 

Spec identification Capacity estimation API design	10 - 15분
High level systems Database schema	10 - 15 분
Component design Scalability Fault tolerance	15 - 20 분

 

 

 

 

각 템플릿에서 신경써야 되는 사항

 

1. Spec Identification

 

✔️ 인터뷰를 리드하되 clarification을 위해 많이 질문하기

 

 

예를 들면,

 

 

"What is the functionality?"

• • Makes sure you & interviewers agree
  • Simplify (only the core functions)

 

"Non-functional attributes"

• • Availability
  • Durability
  • Consistency
  • Performance and cost

 

 

2. Capacity Estimation

 

✔️ 합리적인 숫자 선정하기

• • 유저들은 1M? 아니면 1B?

 

✔️ System capacity 에 대해 계산하고 나열

• • QPS(Queries Per Second)
  • Storage capacity
  • Network bandwidth
  • Number of machines

 

 

 

3. Systems API

 

✔️ Express the core functionality in API

 

이 때도 spec이 정확한지 clarification 질문하기!

 

 

예를 들자면, designing URL shortening 문제의 경우:

 

• • CreateUrl (long_url, user_id, expiration_date) => short_url
  • DeleteUrl (short_url, user_id)

 

 

 

 

4. High level Systems

 

✔️ Draw components

• • User (client devices)
  • Load balancer
  • Blob Storage
  • Database
  • Compute nodes
  • Queues

 

✔️ Data flow

• • Draw lines between components
  • Clearly explain the flow (don't assume)

 

 

 

 

5. Database Schema

 

• Modeling metadata
• Table with primary key and columns (maybe secondary index)
• 몇 개의 table로도 충분하다

 

 

 

 

6. Component Design

 

✔️ Filling the detail

각 디자인 문제마다 요구하는게 다르다.

 

예를 들어 트위터라면, push model을 쓸지 아님 pull model을 쓸지?

데이터는 relational DB 를 이용/ Non-relational DB를 써야 될지?

 

 

✔️ 여기에서 나의 시스템 디자인 깊이를 팍팍 뽐내야 한다!

✔️ Pick 1-2 components

✔️ Consider trade-offs

만약 relational DB를 쓴다면 왜 non-relational DB를 안 쓰는건지, 비교하고 더 나은 점을 설명해줘야 함!

 

 

 

 

7. Scalability & 8. Fault Tolerance

 

• Load-balancing
  • Scale-out
• Caching
  • Cache replacement?
  • How many cache nodes?
• Sharding
  • Range-based?
  • Consistent hashing?
• Replication
  • Consistency?