식당 예약 서비스

시스템 설계 한 번에 인터뷰 합격하기 - 2주차

1단계: QA

• 식당의 수는 얼마나 되나요? 한 곳인가요? 아니면 OpenTable 같이 여러 곳의 식당일까요?
• 여러 식당이 있습니다.

• 사용자 경험을 생각해보면 아래 사항들을 고려해야할까요? 일행 수를 입력 → 예약 시간 선택 → 예약 → SMS 등으로 예약 확인 → 예약 변경/취소
• 핵심 작업은 같다.

• 비용보다는 성능과 안정성 최적화에 집중하나요?
• 확장 가능하고 안정적이면서 로드 시간이 빠른 시스템을 설계하면 된다.

2단계: 설계

설계 포인트

• 요구사항을 명확하게 만들기
• 고객 경험부터 시작
• 그 후 사용하는 기술

• 데이터
• 필요한 데이터 (with Table)
• 데이터 저장 방법
• 분산 방법 및 가용성 (+ 장애대응)

• 확장 가능한 시스템을 설계

• 캐싱

시스템 설계 사례 1

• 테이블 생성
• 고객 정보 테이블
• 레스토랑 정보 테이블
• 예약 정보 테이블
• 고객 정보와 레스토랑 정보를 사용

• 예약 관련
• 예약방법에 대한 고려 필요
• 테이블별 예약이 가능하도록 관리할지
• 인원수와 테이블을 조정하여 예약할 수 있을지 고려

• 캐시
• 캐시를 적용할 만한 부분은 위치정보를 기반한 식당 정보
• 식당 정보는 변경이 잦지 않아 캐싱 가능

• 확장 가능한 시스템 설계
• 로드밸런서와 인스턴스 연결
• 데이터베이스를 다중화 하여 장애 대응

• 데이터베이스 선택
• NoSQL
• 다이나모DB (aws)
• 카산드라
• MongoDB
• RDBMS
• Oracle, MySQL

시스템 설계 사례 2

• API 기능
• 식당 조회(GET)
• 조회 조건 : 메뉴 카테고리, 예약 날짜
• 해당 날짜에 예약이 가능한 식장 목록이 조회 된다.
• 선택한 식당 정보 (GET)
• 선택한 식당에 나의 예약 정보가 있다면 같이 보여주면 좋을 것 같다.
• 예약 등록(POST)
• 고객 정보와 예약 날짜
• 나의 예약 조회 (GET)
• 고객의 ID로 예약 조회 가능
• 예약 변경(PATCH)
• 예약한 식당의 날짜나 시간만 변경 가능하다
• 예약 취소(DELETE)
• 예약 정보 삭제

• DB 테이블
• 고객 정보

customer_id

nickname

name

phone_number

• 식당 정보

res_id	name	address	phone_number	location
식당 고유번호	식당 이름	주소	연락처	위치

• 예약 정보

customer_id	res_id	booking_datetime	count
고객 고유번호	식당 이름	예약 날짜	예약 인원

• 서버 구성 설계



 
1. PC나 모바일을 통해 예약이 가능
2. 로드 밸런서를 통해서 적절히 분산되어 웹서버에 연결
3. 웹서버를 수평적으로 배치
4. 데이터는 Relational Database에 저장되어 관리
5. RDB의 Replication DB를 두어 Master DB에 장애가 발생했을때를 대비
6. Cache 서버를 두어서 식당 조회나 예약 조회로 발생되는 DB의 병목현상을 줄임

3단계: 스터디 후 필요한 내용

인터뷰에서 추가로 고려한 내용들

• 예약시 인원에 따라 테이블을 합쳐야 할지에 대해 복잡한 로직이 요구 될 수 있다.

• 식사 후 다음 대기까지의 시간을 고려하도록 식당에서 예약 시간 제어가 필요하다.

• 식당에서 예약없이 방문할 고객을 얼마나 수용할지도 지정하는 것도 필요하다고 언급

• DB 테이블
• 예약 테이블 컬럼 : Notes (고객 추가 요청에 관한 내용)

• 서버 구성
• Geo-router를 통해서 지리적 위치에 따라 빠르게 접근할 수 있도록 함
• SMS notifications 서버 : 예약 알림을 위한 서버
• RDB가 아닌 NoSQL을 선택
• 어플리케이션에서 내부적으로 각각의 테이블 연결할 수 있다고 판단
• Caching으로 memcached를 선택함.
• 식당/고객 정보는 자주 변경되는 것이 아니기 때문에, 캐싱을 해둘 수 있다.
• 정적인 컨텐츠가 없으므로 CDN까지는 없어도 됨.