설계의 순수성(purity)에 집착한 나머지 타협적 결정(tradeoff)를 도외시하고 과도한 엔지니어링(over-engineering)을 하는 엔지니어가 되면 안 된다.
1단계: 문제 이해 및 설계 범위 확정
부정적 신호(red flag): 요구사항을 완전히 이해하지 않고 답을 내놓는 행위 요구사항을 이해하는 데 필요한 질문
- 구체적으로 어떤 기능들을 만들어야 하나?
- 제품 사용자 수는 얼마나 되나?
- 회사의 규모는 얼마나 빨리 커지리라 예상하나?
- 회사가 주로 사용하는 기술 스택(technology stack)은 무엇인가? 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가?
2단계: 개략적인 설계안 제시 및 동의 구하기
- 면접관을 마치 팀원인 것처럼 대하라.
- 핵심 컴포넌트를 포함하는 다이어그램을 그려라.(클라이언트(모바일/웹), API, 웹서버, 데이터 저장소, 캐시, CDN, 메시지 큐 등)
- 개략적 추정이 필요한지는 면접관에게 미리 물어보고 계산 과정은 소리 내어 설명하라.
- 시스템의 구체적 사용 사례도 살펴보자. 미처 고려하지 못한 에지 케이스(edge case)를 발견할 수 있다.
3단계: 상세 설계
- 시스템의 병목 구간이나 자원 요구량 추정치에 대해 설계하기
- 설계 대상 컴포넌트 사이의 우선순위 정하기
피드 발행에 대한 예시
4단계: 마무리
- 개선할 부분이 없다는 답 X
- 설계를 다시 한번 요약하기
- 오류가 발생하면 모슨 일이 생기는지(서버 오류, 네트워크 장애 등) 따져보기
- 운영 이슈 - 메트릭 수집과 모니터링, 로그, 배포(roll-out) 과정
- 미래에 닥칠 규모 확장 요구에 대처
- 다루지 못한 세부적 개선사항 제안