URL 단축 서비스

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

1단계: QA

• 서비스 규모는 어느 정도인가?
• 경로 재설정 수백만 건이 가능한 서비스로 고려한다.

• 사용할 수 있는 문자의 제한은?
• 유저의 사용성을 고려하여 기호와 대문자는 제외한다.
• 소문자와 숫자만 사용[a-z, 0-9]한다.

• 본인만의 단축 url 지정이 가능한가?
• 가입한 사용자, 유료 사용자에게만 제공한다.

• 생성된 url의 수정/삭제가 가능한가?
• 계정이 있다면 가능하다.

• 단축 url의 지속시간은?
• 영원하다.

• 추가로 질문할 만한 포인트
• 중복 URL에 대해서 같은 단축 URL을 제공해야하는가?
• 한 계정이 등록할 수 있는 최대 갯수는?
• 페이지가 없어진 URL에 대한 관리는 어떻게 하는가?

2단계: 설계

설계 포인트

1. 어떤 API가 필요할까?

2. 큰 규모에서 어떻게 redirection을 할까?

시스템 설계 사례1

• API
• 등록(POST)
• 조회(GET)
• 갱신(PATCH)
• 삭제(DELETE)
• 목록 조회(GET)
• 경로 재지정(GET)

• DB Table
• Id : 등록할때마다 자동으로 생성

• 설계



• LoadBalancer : 서버 부하 분산을 위하여 유저가 접속시 이를 통하게 함.
• Servers : REST API 요청에 대한 응답을 하는 서버
• NoSQL : URL 접속에 대한 조회 요청이 많을 것으로 예상되어 조회에 대한 Cache용으로 사용
• Database : URL 데이터 저장 및 등록/갱신/삭제는 직접 Database에서 진행한다.

시스템 설계 사례2

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

전체 구성

데이터 스키마

• 인덱스
• 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 임시 이동

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

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

• 짧은 URL 을 정하는데 있어서 유저 사용성에 대한 고민

• shortURL을 생성하는 방법에 대한 설명(고유 ID 를 Base36으로 인코딩)

• Add new URL/ Add New Vanity URL을 구분함

• 조회/리다이렉션 API

• 캐시에 대해 구체적인 예시 언급

• DB 인덱스 설정 언급

추가로 알아야 할 것

• PUT과 PATCH의 차이점

• Geolocation

• Vanity URL 의 개념

• 왜 memcached를 Caching DB로 사용하고, NoSQL을 저장용으로 사용했을까?
• Redis vs Memcached
• https://www.linkedin.com/pulse/memcached-vs-redis-which-one-pick-ranjeet-vimal/
• https://www.google.com/amp/s/www.imaginarycloud.com/blog/redis-vs-memcached/amp/
• https://chrisjune-13837.medium.com/redis-vs-memcached-10e796ddd717
• Redis as a database

• HTTP Status Code 301/302
• 공부하기 : https://jvns.ca/blog/2019/09/12/new-zine-on-http/
 

참고