스터디 포스트 >  시스템 설계 한번에 인터뷰 합격하기

식당 예약 서비스

김재엽 멘토
매일 조금씩 발전하려고 노력중인 개발자 입니다 :)

시스템 설계 한 번에 인터뷰 합격하기 - 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
        고객 고유번호
        식당 이름
        예약 날짜
        예약 인원
  • 서버 구성 설계
    • notion image
       
      1. PC나 모바일을 통해 예약이 가능
      1. 로드 밸런서를 통해서 적절히 분산되어 웹서버에 연결
      1. 웹서버를 수평적으로 배치
      1. 데이터는 Relational Database에 저장되어 관리
      1. RDB의 Replication DB를 두어 Master DB에 장애가 발생했을때를 대비
      1. Cache 서버를 두어서 식당 조회나 예약 조회로 발생되는 DB의 병목현상을 줄임
 

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

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

  • 예약시 인원에 따라 테이블을 합쳐야 할지에 대해 복잡한 로직이 요구 될 수 있다.
  • 식사 후 다음 대기까지의 시간을 고려하도록 식당에서 예약 시간 제어가 필요하다.
  • 식당에서 예약없이 방문할 고객을 얼마나 수용할지도 지정하는 것도 필요하다고 언급
  • DB 테이블
    • 예약 테이블 컬럼 : Notes (고객 추가 요청에 관한 내용)
  • 서버 구성
    • Geo-router를 통해서 지리적 위치에 따라 빠르게 접근할 수 있도록 함
    • SMS notifications 서버 : 예약 알림을 위한 서버
    • RDB가 아닌 NoSQL을 선택
      • 어플리케이션에서 내부적으로 각각의 테이블 연결할 수 있다고 판단
    • Caching으로 memcached를 선택함.
      • 식당/고객 정보는 자주 변경되는 것이 아니기 때문에, 캐싱을 해둘 수 있다.
    • 정적인 컨텐츠가 없으므로 CDN까지는 없어도 됨.
    •  
 

 
 
본 스터디는 Udemy의 <【한글자막】 Machine Learning 완벽 실습 : 6가지 실제 사례 직접 해결하기> 강의를 활용해 진행됐습니다. 강의에 대한 자세한 정보는 아래에서 확인하실 수 있습니다.
 
 
프밍 스터디는 Udemy Korea와 함께 합니다.
 
 

 
원하는 스터디가 없다면? 다른 스터디 개설 신청하기
누군가 아직 원하는 스터디를 개설하지 않았나요? 여러분이 직접 개설 신청 해 주세요!
이 포스트는
"시스템 설계 한번에 인터뷰 합격하기" 스터디의 진행 결과입니다
진행중인 스터디
시스템 설계 한번에 인터뷰 합격하기
외국계 뿐만이 아니라 국내 기업 채용에서도 시스템 설계 인터뷰를 진행하고 있습니다. 그리고 junior와 senior를 구분짓는 능력 중 하나를 시스템 설계를 꼽고 있습니다. 개발자로서 그만큼 중요한 능력을 방향성을 잡고 제대로 키우기 위해서 이번 기회에 준비해보고자합니다.
김재엽 멘토
매일 조금씩 발전하려고 노력중인 개발자 입니다 :)