모의 설계 인터뷰 - URL 단축 서비스

서비스 소개

URL 단축 서비스

• 기존의 url을 짧은 url로 대체하고 경로 재설정을 관리하는 서비스
• ex) bit.ly

Q&A

• 어느 정도 규모인지?
  • 경로 재설정 수백만 건, url 수백만개
• 사용할 수 있는 문자의 제한은?
  • 기호 x - 기억/타이핑 어려움
  • 소문자, 숫자만 사용
• 얼마나 짧아야 하는지?
  • Base36 사용 (a-z 26개 + 0-9 10개)
  • 6자리 사용하면 36^6개 => 21억개 이상이므로 충분할 것으로 예상됨
• 본인만의 단축 url 지정이 가능한지?
  • 가입한 사용자 또는 유료사용자만 가능하게
• 생성된 단축 url의 수정/삭제가 가능한지?
  • 계정 있다면 가능
• 단축 url의 지속기간은?
  • 영원히

시스템 설계

API 설계

• POST Add new url
  • long url, user Id = null -> status, short url
  • 모든 url은 순차 ID 얻음 -> 이걸 base36 인코딩
  • 동일한 url이어도 id가 다르기 때문에 문제 없이 사용 가능
  • 해시 함수는 동일 url의 경우 해시 충돌이 나는 걸 해결해야 함
• POST Add new vanity url
  • long url, user ID, vanity url -> status
• PATCH Update url
  • long url, user ID, updated long url -> status, existing short url
• DELETE Delete url
  • long url, user ID -> status
• GET Display mapping
  • long url, user ID -> status, short url
• GET Redirect
  • short url -> redirect to long url

전체 구성

데이터 스키마

id	user_id	short_url	long_url
pk	사용자 id	단축 url(id를 base36 인코딩한 값)	원본 url

• 인덱스
  • short_url 검색용 - short url -> long url 매핑
  • long_url 검색용 - long url 수정시

진행과정

• 클라이언트가 API 요청, short url 보냄
• 로드밸런서가 요청을 서버에 분산
• 매핑할 long url이 캐시에 있는지 확인
  • redirect 요청시마다 디스크 히트 피할 수 있음
  • 매핑 수정될 일 거의 없으므로 오랫동안 캐시 가능
• 캐시에 없으면 데이터 베이스에서 가져옴
  • DB는 확장 가능성 고려해서 NoSQL 사용
• 가져온 long url으로 경로 재지정 리턴
  • 없으면 404 리턴

추가 정리

• shortened url vs. vanity url
  • long url = "velog.io/@inhalin"
  • shortened url 생성 -> bit.ly/AbCDe
  • vanity url 생성 -> inhal.in/AbCDe
• HTTP 상태 코드
  • 301 Permanently moved 영구 이동
  • 302 Temporarily moved 임시 이동
• 캐시
  • 강의에서는 캐시용으로 memcached, 디비 저장용으로 redis 사용
  • 두개 차이점
• RDB vs. NoSQL
  • RDB보다 확장성이 더 용이함(정확히 어떤 부분에서?)
  • 데이터가 얼마나 많이 저장하나, 읽기를 얼마나 사용하나에 따라
  • 게임서버는 데이터 저장에서 신뢰할 수 있는 부분에서는 RDB 사용
  • RDB 샤딩, 클러스터 지원함, 스케일아웃 가능함
  • 데이터 사용 목적, 용도에 따라 적절히 선택

참고

https://metalkin.tistory.com/50
https://metalkin.tistory.com/53
https://developer.mozilla.org/ko/docs/Web/HTTP/Status