​​문제 단축도메인 (요구사항)원본 URL을 단축 URL로 변환하는 서비스를 개발하고자한다.API 설계와 DB 설계를 해야한다고 할때 어떻게 할 수 있을지 아키텍쳐 관점에서 생각해본다.단축 URL의 키는 path에 해당하는 경로를 의미한다.​​​​문제 분석세 가지 API를 설계해야한다.단축 URL 생성 API원본 url을 단축 url로 변환해주는 api이다.해당 api를 타고 가면 키 생성 알고리즘에 따라 유니크한 단축 url 키가 생성된다.단축 URL 리다이렉트 API단축 url 경로로 웹 브라우저를 통해 전달되면 단축 url 서비스에서는 원본 url로 리다이렉션 시켜주어야한다.단축 url 키와 매핑된 원본 url을 가져와 단축도메인 리다이렉트 한다.단축 URL 정보 조회 API단축 url을 입력하면 해당 하는 원본 url의 정보를 리턴해준다.부가 옵션으로 필수적으로 필요한 기능은 아니다.​​​​고민 사항단축 url 키의 길이밀러의 법칙에 의하면 사람은 단기적으로 7 ± 2개의 정보 단위(chunks)를 기억할 수 있다고 한다.단축 url을 사용하는 이유는 원본 url이 너무 길기에 가독성이 떨어지기 때문이다.사용자 편의성뿐만 아니라 서비스 비용(데이터) 측면에서도 너무 많은 자리수를 가진 단축 url을 설정하면 비용이 많이 발생할 것이다.따라서 7자리 Base62 (62진수) 로 표현 가능한 조합으로 제한한다. 이렇게 단축도메인 되면 약 3.5 조 개의 고유 url 키를 생성 가능하다.​키 생성 알고리즘Base64는 64개의 문자를 사용해서 효율은 좋지만, URL에 넣기엔 부적절한 문자가 포함되어 있다.+ → URL에서 공백으로 인식될 수 있음/ → URL 경로 구분자로 사용됨=→ Base64 인코딩의 패딩 문자, URL의 쿼리 파라미터 구분자로 쓰이기도 함url safe한 Base64가 있지만 해당 문자를 제거한 Base62로 인코딩하는 것이 더 안전하고 간편하다.62진수로 표현한 7자리 최대값은 zzzzzzz이며 10진수로 3,521,614,606,207 로 변환된다.​​​​HTTP 302 vs HTTP 301bitly같은 서비스를 사용하며 브라우저 단축도메인 헤더 정보를 보면 301을 사용하는 것을 확인할 수 있다.3xx번대에 301이외에도 302가 존재한다. 이 둘의 차이는 무엇일까?​​​HTTP 301 (Moved Permanently)301 상태 코드는 “이 주소는 영구적으로 다른 곳으로 이동했다”는 의미이다.서버가 이 코드를 응답하면, 클라이언트(브라우저)는 기존 URL 대신 새 URL로 계속해서 접근해야 한다고 인식한다. 즉, 처음 한 번은 서버에 요청을 하지만, 이후부터는 브라우저가 새 URL을 기억해서 다음 요청 때는 자동으로 새 주소로 이동한다. ​이 때문에 301 리다이렉션은 검색 엔진 최적화(SEO)에도 중요하다. 검색 엔진은 원래 단축도메인 주소 대신 새 주소를 인덱싱하고, 검색 순위도 새 주소에 이전된다. 그래서 도메인 변경, 페이지 주소 변경처럼 URL 구조가 영구적으로 바뀌었을 때 301 리다이렉션을 사용한다.​​HTTP 302 (Found, 혹은 Moved Temporarily)302 상태 코드는 “이 주소가 일시적으로 다른 곳으로 이동했다”는 의미이다.클라이언트는 이 응답을 받으면, 당장은 새 URL로 이동하지만 이 이동이 영구적이지 않다고 생각한다.따라서 브라우저는 이 리다이렉션 정보를 저장하지 않고, 다음 번 요청 시에는 원래 URL로 다시 요청을 보낸다. 주로 로그인 후 대시보드 이동, 임시 단축도메인 이벤트 페이지, 또는 특정 상황에서만 잠시 다른 페이지로 보내야 할 때 사용한다. 검색 엔진은 302 리다이렉션을 받을 경우 원래 주소를 유지해서 인덱싱한다.​​무엇을 선택할까?서버 부하를 줄이는 것이 중요하다면 301 Permanenly Moved를 사용하는 것이 좋다.반면 트래픽 분석이 중요할 때는 302 Found를 쓰는 쪽이 클릭 발생률이나 발생 위치를 추적하기에 용이하다.서비스 특징에 맞추어 사용하면 좋을 것 같다.​​​​​필요한 기능단축 url 주소를 원본 url 주소로 치환해서 응답해줄 url 맵핑 서비스Base62를 이용하여 짧은 식별자를 생성하여 단축 url을 생성 단축도메인 해줄 키 생성 서비스DBMS에서 모든 URL 매핑 요청마다 매핑정보 처리를 담당하게되면 부하가 발생. 따라서 Rate Limiter 를 넣어 요청량을 조절하고, 인메모리 형태의 key-value DB를 사용해 캐싱 기능3조 5천개의 모든 데이터를 가지게 되면 서버 유지 비용이 과도하게 발생. 따라서 주기적으로 데이터를 정리해주는 cleanup 서비스​​​​​시나리오 ​단축 URL 생성 시나리오1. 원본 URL을 입력2. 데이터베이스에 해당 URL이 있는지 검사3. 존재하면 맵핑된 단축 URL을 클라이언트에게 반환4. 존재하지 않는다면 유니크 ID(데이터베이스 기본 키)를 생성 후 62진법 변환을 단축도메인 적용하여 단축 URL 키 생성​​6. ID, 단축 URL, 원본 URL로 레코드를 생성 후 단축 URL을 클라이언트에 반환 ​URL 리디렉션 시나리오1. 사용자가 단축 URL을 브라우저에 입력2. 요청을 웹 서버에 전달3. 단축 URL이 이미 캐시에 있는 경우에는 원본 URL을 바로 조회하여 클라이언트에게 전달4. 캐시되지 않은 URL의 경우 데이터베이스에서 조회.5. 데이터베이스에도 존재하지 않는 경우 잘못된 단축 URL임으로 에러 반환5. 데이터베이스에 존재하는 경우 조회한 원본 URL을 캐시에 저장 후 클라이언트 리디렉션​​​​예시코드​​​​​​​참조Base62의 이해와 URL Shortener​