요구사항과 두 경로의 무게

읽기와 쓰기의 비율입니다. 조회가 생성의 100배입니다.

그래서 최적화 대상이 분명합니다. 쓰기가 조금 느린 것은 괜찮고 읽기가 조금 느린 것은 안 됩니다. 이 비율은 서비스 성질에서 나옵니다. 링크는 한 번 만들어 여러 번 공유됩니다.

그다음 키 7자 이하 와 누적 300억 개 을 함께 봅니다. 두 값이 키 공간 계산을 강제합니다.

흔한 실수: 키를 만드는 방법부터 논하는 것. 그것도 필요하지만 비율을 먼저 말하지 않으면 왜 캐시가 중심이고 왜 쓰기 경로를 단순하게 두는지 설명할 수 없습니다.

쓰기 전에 조회하지 않기 위해서입니다.

재사용하려면 키를 만들기 전에 그 주소가 이미 있는지 찾아야 합니다. 누적 300억 개 규모에서 원래 주소로 찾으려면 그 값에 대한 인덱스가 따로 필요하고, 주소는 길어서 인덱스가 큽니다.

포기하면 쓰기가 조회 없이 끝난다
같은 주소에 키가 여러 개 생긴다

대가는 저장 공간을 조금 더 쓰는 것입니다. 사용자에게는 문제가 되지 않습니다.

흔한 실수: 중복 제거를 당연히 해야 하는 것으로 보는 것. 무엇을 위해 하는지 물어야 합니다. 저장 공간을 아끼려는 것이면 그 절약이 조회 인덱스 비용보다 큰지 계산해야 하고, 이 규모에서는 아닙니다.

서로를 밀어냅니다. 단축기의 존재 이유는 주소가 짧아지는 것인데, 짧으면 담을 수 있는 개수가 줄어듭니다.

키가 길어지면 서비스의 값이 떨어진다
키가 짧아지면 담을 수 있는 개수가 줄어든다

그래서 필요한 개수를 담는 가장 짧은 길이를 찾는 것이 이 설계의 첫 계산입니다. 감으로 정하면 나중에 길이를 늘려야 하고, 그때 이미 발급한 짧은 키와 섞이게 됩니다.

흔한 실수: 길이를 넉넉하게 잡아 두는 것. 다른 설계에서는 여유가 안전이지만 여기서는 여유가 곧 서비스 가치의 손실입니다. 요구사항이 길이 상한을 정한 이유가 그것입니다.

뒤의 결정에 묶여 있기 때문입니다.

리디렉션은 우리 서버를 지나가므로 그 순간에 세면 추가 비용이 거의 없습니다. 그런데 리디렉션 응답을 어떻게 고르는지에 따라 요청이 우리 서버에 오지 않을 수 있습니다.

브라우저가 응답을 기억하면 다음 방문은 우리를 지나지 않는다
그러면 조회 수가 세어지지 않는다

요구사항에 적어 두면 그 결정을 할 때 이 기능을 놓치지 않습니다.

흔한 실수: 기능 목록을 서로 독립적인 항목으로 보는 것. 어떤 기능은 다른 결정의 결과로 동작하지 않게 됩니다. 요구사항 단계에서 적어 두는 것이 그것을 발견하는 방법입니다.