Foundry
URL 단축기 설계
심화
핵심

어떤 응답으로 보낼지

지나가야 세고 바꿀 수 있다

키로 원래 주소를 찾았습니다. 이제 브라우저를 그 주소로 보냅니다. 어떤 응답으로 보내는지가 이 서비스의 두 기능을 좌우합니다.

응답 코드의 뜻 자체는 HTTP 상태 코드 개념에서 다뤘습니다. 여기서는 단축기에서 그 선택이 만드는 결과만 봅니다.

영구와 임시의 차이가 만드는 것

영구 이동으로 답하면 다음 방문이 서버를 지나지 않고 임시 이동은 매번 지나간다 영구 이동으로 답하면 첫 방문 우리 서버 다음 방문 지나지 않는다. 브라우저가 기억한다 한 번만 온다 임시 이동으로 답하면 매 방문 우리 서버 늘 지나간다 지나가야 조회 수를 세고 대상 주소를 바꿀 수 있다 그래서 무엇을 포기할지가 이 응답 선택이다

영구 이동으로 답하면 브라우저가 그 대응을 기억합니다. 다음부터는 우리 서버를 지나지 않고 곧바로 목적지로 갑니다.

항목영구 이동임시 이동
두 번째 방문우리를 지나지 않는다지나간다
사용자 체감더 빠르다왕복 한 번
우리 서버 부하크게 줄어든다조회마다 받는다
조회 수 세기첫 방문만 센다모두 센다
대상 주소 변경반영되지 않는다반영된다

이 요구사항에서는 임시를 고른다

요구사항에 조회 수 세기가 있습니다. 영구로 답하면 그 기능이 동작하지 않습니다. 첫 방문만 세고 나머지는 보이지 않으므로 숫자가 실제보다 훨씬 작게 나옵니다.

그리고 만료 기능도 영향을 받습니다. 브라우저가 기억한 대응은 우리가 만료시켜도 그 브라우저에서는 계속 동작합니다.

조회 초당 1만 를 모두 받는 대가를 냅니다. 그 부하를 감당하는 것이 다음 개념의 주제입니다.

되돌릴 수 없는 선택이다

영구 이동은 브라우저에 오래 남습니다. 잘못 응답한 대응을 우리가 지울 방법이 없습니다.

잘못된 목적지로 영구 이동을 보내면
그 브라우저는 우리에게 다시 묻지 않는다

그래서 영구를 고르려면 그 대응이 절대 바뀌지 않는다는 확신이 필요합니다. 단축 링크는 대상이 바뀌거나 만료되는 종류라 그 확신이 없습니다.

응답 본문을 비워 둔다

리디렉션 응답에는 본문이 필요 없습니다. 목적지 주소만 헤더에 담으면 됩니다. 조회 초당 1만 에 본문이 붙으면 그만큼의 전송량이 곱해집니다.

조회 수를 응답 경로에서 세지 않는다

리디렉션은 50ms 안에 끝나야 합니다. 조회 수를 세는 저장을 그 경로에서 기다리면 예산을 씁니다.

목적지를 먼저 응답한다
조회 수는 뒤로 넘겨 모아서 센다

정확한 실시간 숫자가 필요한 기능이 아니므로 모아서 세는 편이 맞습니다. 몇 초 늦게 반영되는 것을 요구사항에서 허용해 두면 이 선택이 자유로워집니다.

면접에서 이렇게 나옵니다

Q.리디렉션 응답을 어떻게 고르시겠습니까

임시 이동으로 답합니다. 요구사항에 조회 수 세기가 있기 때문입니다.

영구 이동으로 답하면 브라우저가 그 대응을 기억해 다음부터 우리를 지나지 않습니다.

항목영구임시
두 번째 방문우리를 지나지 않는다지나간다
조회 수첫 방문만 센다모두 센다
대상 변경반영되지 않는다반영된다
우리 부하크게 줄어든다조회마다 받는다

대가는 조회 초당 1만 를 모두 받는 것입니다.

흔한 실수: 성능만 보고 영구를 고르는 것. 더 빠르고 부하도 줄지만 요구사항의 기능 두 개가 동작하지 않게 됩니다. 무엇을 잃는지 말하지 않고 고르면 안 됩니다.

Q.영구 이동이 되돌릴 수 없다는 것은 무슨 뜻인가요

브라우저가 기억한 대응을 우리가 지울 방법이 없습니다.

잘못된 목적지로 영구 이동을 보내면
그 브라우저는 우리에게 다시 묻지 않는다

만료도 같은 문제입니다. 우리 쪽에서 링크를 만료시켜도 이미 기억한 브라우저에서는 계속 동작합니다.

그래서 영구를 고르려면 그 대응이 절대 바뀌지 않는다는 확신이 필요합니다. 단축 링크는 대상이 바뀌거나 만료되는 종류라 그 확신이 없습니다.

흔한 실수: 캐시 유지 시간을 짧게 지정해 완화하려는 것. 지정할 수 있지만 중개 서버와 오래된 클라이언트가 그것을 지키지 않을 수 있고, 지키지 않는 쪽을 우리가 알 방법이 없습니다.

Q.조회 초당 1만 를 모두 받으면 조회 수는 어떻게 세나요

응답을 먼저 주고 세는 일은 뒤로 넘깁니다.

리디렉션은 50ms 안에 끝나야 하므로 조회 수 저장을 그 경로에서 기다리면 예산을 씁니다.

목적지를 먼저 응답한다
조회 수는 모아서 나중에 센다

정확한 실시간 숫자가 필요한 기능이 아닙니다. 몇 초 늦게 반영되는 것을 요구사항에서 허용해 두면 이 선택이 자유로워집니다.

흔한 실수: 조회마다 저장소의 값을 하나 올리는 것. 초당 1만 번의 쓰기가 되고, 인기 링크 하나에 그 쓰기가 몰립니다. 그 링크의 카운터가 병목이 되는 것은 읽음 표시에서 본 것과 같은 문제입니다.

Q.리디렉션 응답에서 또 무엇을 줄일 수 있나요

본문을 비웁니다. 목적지 주소만 헤더에 담으면 됩니다.

조회가 초당 1만이므로 본문 한 줄도 그만큼 곱해집니다. 사람이 읽을 안내 문구를 넣고 싶어도 브라우저는 곧바로 이동하므로 아무도 보지 않습니다.

그리고 조회 경로에 붙는 다른 것도 함께 봅니다.

항목판단
응답 본문비운다
조회 수 저장뒤로 넘긴다
사용자 인증공개 링크라면 필요 없다
로그표본만 남긴다

흔한 실수: 리디렉션 경로에 이것저것 붙이는 것. 이 경로는 서비스에서 가장 많이 실행되는 코드라 여기 붙는 모든 것이 초당 1만 배로 곱해집니다.

먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.

읽었으면 문제로 확인해보세요

URL 단축기 설계 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.