1단계 요구사항 분석

• 매일 1억개의 단축 URL 생성
• 초당 1160(100million/24/3600)
• 읽기연산과 쓰기연산의 비율을 10:1이라고 할때 읽기연산은 초당 11,600회
• URL 단축 서비스를 10년간 운영한다고 가정하면 3650억 개의 레코드를 보관해야함
• 축약 전 URL의 평균 길이를 100이라고 하면 10년 동안 필요한 저장 용량은 3650억 * 100 바이트 → 36.5TB

2단계 개략적설계안 제시 및 동의 구하기

API엔드포인트

REST스타일 설계 하에서 URL단축기는 기본적으로 두 개의 엔드포인트를 필요로 한다.

• URL 단축용 엔드포인트
  • 새 단축 URL을 생성하고자 하는 클라이언트는 이 엔드포인트에 단축할 URL을 인자로 실어서 POST요청을 보내야한다. 쉽게 말해 단축 URL을 얻는 API를 요청한다는 것
  • POST /api/v1/data/shorten
    • parameter : {longUrl: longUrlString}
    • return : 단축 url
• URL 리디렉션용 엔드포인트
  • 단축 URL에 대해서 http 요청이 오면 원래 URL로 보내주기 위한 용도의 엔드포인트
  • GET /api/v1/shortUrl
    • 반환 : HTTP 리디렉션 목적지가 될 원래 URL

URL 리디렉션

• 응답 상태 코드의 차이
  • 301 permanenetly moved → 요청에 대한 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 응답
    • 영구적으로 이전되었기 때문에 브라우저는 응답을 캐시 처리하여 재 요청이 들어왔을 경우 캐시된 api를 참조한다.
  • 302 Found → 주어진 URL로의 요청이 일시적으로 Location 헤더에 반환된 URL에 의해 처리되어야 한다는 응답
    • 캐시하지 않고 항상 단축 URL 서버에 요청해야함.
  • 서버 부하를 줄이기 위해서는 301, 트래픽 분석이 중요할 때는 302를 사용하자
• URL 리디렉션을 구현하는 가장 직관적인 방법은 해시 테이블을 사용하는 것
  • 원래 URL = hashTable.get(shorten URL)
  • 301, 302 reposnse 와 URL을 header 담아 전송

URL 단축

• 해시함수 요구사항
  • 입력으로 주어지는 URL이 다른 값이면 해시 값도 달라야한다.
  • 게산된 해시 값은 원래 입력을 주어졌던 긴 URL로 복원가능해야한다.