# System Design

- 시스템 디자인에 대한 질문은 대게 어떻게 **complex large scalable (distributed) system** 를 어떻게 만들 것인가에 대한 질문이다.

> 출처: https://www.geeksforgeeks.org/how-to-crack-system-design-round-in-interviews/

Step by Step
---

1. **시스템의 목적을 이해하고, 모든 요구사항을 수집한다**
- 시스템이나 서비스의 최종 목적은?
- 엔드 유저는 누가 있을까? 어떻게 사용할까?
- 시스템에 넣어야 할 기능과 빼야할 기능은 어떤 것이 있을까?
- 인풋과 아웃풋은 어떤 것이 있을까?
2. **시스템 인터페이스 정의와 범위 수립**
- 시스템의 기능을 수행하기 위해서 어떤 식의 API 가 존재해야할까? (*REST API? GraphQL? RPC?*)
- 시스템이 다운되었을 때도 서비스가 지속할 수 있을까?
3. **확장성 측정**
- 서비스가 몇 명의 엔드 유저를 타겟으로 하는지, 수천명, 수백만명의 사람들이 접속해도 문제가 없는 시스템인지
- 요청이나 사용자가 증가했을 때 확장 가능한 솔루션인가?
- 여기서 이야기하는 확장성이란, **load balancing**, **caching**, **partitioning** 등이 있음
- 측정하기 위한 요소로는 스토리지 용량, 평균 응답시간, bandwidth 등
4. **high level component 부터 시작해서 세세한 디자인으로 확장하자**
- 시스템을 6~7개의 core component 로 구분해보자
- 각각의 component 들에 대한 역할과 책임에 대해서 정의하고, 이들이 서로 어떻게 상호작용하는지에 대해서 정의하자.
- Component의 예시에는 *frontend, backend, networking, caching, load balancing, queueing, database, external API call, user interaction, offline process* 등이 있음
- DB 또는 특정 기술 스택에 대해서 왜 쓰는지를 설명해야한다.
5. **Tradeoff 와 Bottleneck**
- 시스템을 설계했을 때 발생할 수 있는 tradeoff는?
- Complex system 은 항상 tradeoff 를 동반하는데 그 장단점에 대해서 설명할 수 있어야 함.
- 예를 들어, 특정 데이터 베이스를 왜 사용했나 / 특정 레이어의 기술스택은 어떤 기준에서 선택했나 / 어떤 프레임워크가 이러한 구조를 짰을 때 효율적이었나 / 보안 측면에서 데이터를 안전하게 보호하는 방법에는 어떤 것이 있나?
- 시스템에서 failure point 가 어디서 발생할 수 있는지를 알고 여기에 대한 솔루션을 제시해야함. 예를 들어, 서버 crash 가 발생했을 경우와 데이터 전체가 손실되었을 때 어떤 복구 방안이 있는지 제시를 할 수 있어야함. 이러한 failure를 대비하기 위해서 모니터링할 수 있는 시스템도 제안해야함.

인터뷰 팁
---

- 80-20 rule을 기억할 것. 인터뷰 시간의 80%는 나의 아이디어를 제안하는데 시간을 투자해야하고, 20%의 시간은 인터뷰어가 말할 수 있는 시간을 남겨둬야한다.
- Buzzword 를 사용하지 말고, 잘 모르는 것에 대해서 아는 척 하지 말아야 한다. 예를 들어서 NoSQL 이라던가 MongoDB, Cassandra 와 같은 단어를 봤다고 그걸 기술 스택에 포함시키는 등 잘 알지 못하면서 buzzword 를 남발하는 것은 지양해야한다.
- 시간 제한이 있기 때문에 하나의 컴포넌트에 너무 많은 시간을 할애하는 것을 지양하자. 너무 디테일하게 이야기하면 오히려 시간 부족하고, 인터뷰어에게 이야기할 여지가 없을 수 있다
- MVC 패턴이라던지 event driven 이라던지 이런 구조를 마음속에 두고 요구사항을 끼워맞추지 말자. 왜냐하면 요구사항에 딱 맞지 않을 수 있기 때문이다. 변경되는 요구사항에 맞춰서 유연하게 대응할 수 있는 상황이 올 수 있기 때문에 이 점은 염두해둬야 한다

예제들
---

### 1. Tiny URL 서비스를 만들어 보자
- 기능
- full url 을 주면 short url 을, short url 을 주면 full url 로 redirect / custom short URL 을 지원
- 사용하지 않는 URL 은 제거함.
- 트래픽: 초당 1000개의 요청
- 모니터링: click stats 를 수집
- 고려사항
- API (REST API) : 어떻게 엔드 유저가 서비스를 사용할 것인지 인터페이스를 고려하고, 로드 밸런싱은 어떻게 할지 고려해야함.
- Application Layer: worker thread 또는 호스트가 어떻게 tiny URL 을 생성하고 이 정보를 DB 에서 관리할 수 있는지 고려
- Persistence Layer: Database
- 자세히
### 2. 유튜브나 넷플릭스를 만들어보자 (global streaming service)
- TBD
### 3. 페이스북이나 왓츠앱을 만들어보자 (global chat service)
- TBD
### 4. Quora, Reddit, HackerNews 를 만들어보자 (social network + message board service)
- TBD
### 5. Search Typeahead 를 만들어보자
- TBD
### 6. Dropbox, Google Drive, Google Photo 를 만들어 보자 (global file storage and sharing service)
- TBD
### 7. Web crawler 를 만들어보자
### 8. 트위터나 인스타그램을 만들어보자
### 9. 우버나 리프트를 만들어보자 (ride sharing service)
### 10. API rate limiter (Github) 를 만들어보자
### Etc. (확장 버전) 블록체인 월렛 (블록체인 지갑) / NFT 민팅 플랫폼 (민팅) / 이더스캔 (온체인 데이터 분석) / 오픈씨 (거래소) 를 개발해보자

MSA 란

Serverless Architecture 란

웹소켓과 HTTP, TCP 등의 관련성. 즉, 거래소에서 사용하는 실시간 데이터 스트리밍은 어떻게 처리가 될까?

Event Driven programming 이란 어떻게 설계하는 것일까?

Kafka 란?