자동 키와 사용자 alias를 같은 도메인 namespace에서 유일하게 관리합니다.
URL 단축 서비스
설계
짧은 키를 발급하는 일보다 중요한 것은, 수억 번의 리다이렉트를 빠르게 처리하면서도 삭제·만료·악성 링크 차단을 되돌릴 수 있게 만드는 일입니다.
개념 이해리다이렉트 정책장애 대응운영 관점진도 저장
30초 핵심 요약
자동 키는 유일한 ID를 Base62로 인코딩하거나, 무작위 후보를 만들고 고유 제약으로 충돌을 확정해 발급합니다. 방문 경로는 캐시 → 저장소 → `Location` 리다이렉트로 짧게 유지하되, 만료·삭제·차단 상태도 캐시에 함께 넣습니다.
키 발급Base62 + unique insert
읽기 우선순위Edge cache → DB
철회 안전성Tombstone + purge
01 · REQUIREMENTS
# 요구사항짧은 주소와 안전한 철회를 함께 만든다
작성자·방문자·운영자의 경로는 다릅니다. 데이터 모델과 캐시 정책은 리다이렉트 성능뿐 아니라 목적지를 나중에 제거할 수 있는지까지 결정합니다.
`GET`/`HEAD`는 cache hit에서 저장소 왕복 없이 목적지로 보냅니다.
만료·삭제·차단 상태는 어떤 cache layer에서도 목적지보다 먼저 확인합니다.
악성 URL 신호와 계정·도메인·IP 기반 운영 제어를 구분합니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처생성·저장·캐시·검사를 서로 분리한다
생성의 비동기 검사와 클릭 분석은 리다이렉트의 p99를 막지 않습니다. 단, cache value에는 URL만 아니라 상태·만료·정책 버전이 포함되어야 합니다.
URL 단축 서비스의 두 경로 SVG DIAGRAM · 생성 / 저장 / 캐시 리다이렉트 / Safe Browsing
중요: 리다이렉트 cache의 TTL과 브라우저·공유 cache가 HTTP 응답을 저장하는 기간은 같은 값이 아닙니다. 삭제·차단은 cache purge와 짧은 TTL로 돕되, 이미 장기 저장된 영구 리다이렉트를 즉시 회수할 수 있다고 가정하지 않습니다.
03 · WRITE / READ FLOW
# 쓰기·읽기충돌은 DB에서 확정하고, 읽기는 상태까지 캐시한다
무작위 키는 확률적으로 겹칠 수 있습니다. 후보를 다시 뽑는 것과 `UNIQUE(domain, short_key)`가 거부하는 것을 함께 써야 잘못된 목적지 연결을 막을 수 있습니다.
허용 scheme와 alias를 검사하고 이전 동일 요청 결과를 돌려줍니다.
유일 ID 인코딩 또는 CSPRNG 후보 생성 뒤 고유 삽입을 시도합니다.
pending_scan으로 저장하고 검사·정책 판정 뒤 active로 전환합니다.
cache hit에서도 status, expiry, version을 보고 redirect 여부를 결정합니다.
클릭 이벤트는 응답 뒤에 보내고 삭제·차단은 purge로 전파합니다.
04 · TRADEOFFS
# 트레이드오프리다이렉트 코드는 캐시 수명과 메서드에 관한 약속이다
RFC 9110·9111에 따르면 301·308은 heuristic freshness를 계산할 수 있고, 302·307은 `Cache-Control`의 `max-age` 같은 명시적 정책으로 caching을 통제하는 편이 안전합니다. 301·302는 POST를 GET으로 바꿀 수 있으나 307·308은 요청 메서드를 바꾸면 안 됩니다.
| 선택 | 캐시·메서드 의미 | 장점 | URL 단축에서의 판단 |
|---|---|---|---|
| 301 Moved Permanently | heuristic freshness 가능, POST→GET 변경 가능 | 안정된 목적지의 반복 방문 효율 | 목적지가 정말 고정일 때만 긴 freshness와 함께 사용 |
| 302 Found | 명시적 캐시 정책 권장, POST→GET 변경 가능 | 변경·철회 가능한 링크의 보수적 시작점 | 일반 GET 링크와 짧은 `Cache-Control`에 적합 |
| 307 Temporary Redirect | 명시적 캐시 정책 권장, 메서드 보존 | 임시 이동에서도 메서드·body 보존 | 비-GET 전달이 의도된 특수 경로만 검토 |
| 308 Permanent Redirect | heuristic freshness 가능, 메서드 보존 | 영구 이동의 명시적 메서드 보존 | 회수 어려움이 허용되는 영구 목적지에 한정 |
| 무작위 Base62 | 후보 충돌 가능, unique insert로 확정 | 순번 추측을 낮춤 | 재시도율·난수 품질·키 길이를 운영 지표로 관리 |
05 · FAILURE MODES
# 장애 6가지네 가지를 넘는 장애를 상태·지표·복구 검증으로 다룬다
캐시 stampede
인기 키가 동시에 miss되어 DB와 redirect p99를 밀어 올립니다.
대응 · single-flight, stale 정책, hot-key rate limit. 피크 재현에서 DB read와 p99를 검증합니다.
키 충돌·alias 경쟁
무작위 후보가 겹치거나 두 사용자가 같은 alias를 요청합니다.
대응 · DB unique constraint, 후보 재생성, 원자적 alias 예약. 중복 key 0건을 확인합니다.
삭제 purge 지연
철회한 링크가 edge나 L1의 오래된 값으로 잠시 열릴 수 있습니다.
대응 · tombstone, purge 재시도, 짧은 TTL, version 검사. 모든 계층의 버전을 대조합니다.
DB/리전 장애
origin miss가 실패해 정상 링크도 리다이렉트하지 못합니다.
대응 · 다중 AZ 읽기·제한적 stale cache·쓰기 보호. failover 뒤 status/expiry 일치를 확인합니다.
검사 공급자 지연
새 링크 판정이 늦거나 타임아웃되어 공개 여부가 불명확해집니다.
대응 · pending 유지, 재시도, 수동 검토. 검사 큐 age와 판단 감사 가능성을 검증합니다.
피싱 대량 생성
봇이 계정·도메인·IP를 바꾸며 링크와 검사 비용을 폭증시킵니다.
대응 · 단계적 rate limit, CAPTCHA, account kill switch. 우회율과 정상 오류율을 함께 봅니다.
06 · OPERATIONS
# 운영보안·관측·비용은 redirect 경로 밖에서 준비한다
Safe Browsing은 URL 위험 신호이고, 관리자 abuse control은 계정·도메인·IP·신고를 다루는 별도 제어 평면입니다. URL query의 토큰과 클릭 원문 로그를 최소화합니다.
allowlist · pending_scan · audit
cache hit ratio, redirect p99, key collision retry, purge lag, scan queue age, blocked/expired 응답을 분리해 봅니다. 목적지 URL은 trace에 원문 대신 ID·안전한 해시를 씁니다.
purge_lag_seconds · decision_total
redirect 본문이 작아도 edge 요청·egress·DB miss·복제·tombstone·검사 호출·수동 검토 비용이 듭니다. hit ratio 95%→90%는 origin read를 두 배로 만듭니다.
cache miss × DB read × replica
면접 모드 · 추가 질문05:00
“하루 2억 번 열리는 URL 단축 서비스를 설계해 보세요. Base62 키 충돌을 어떻게 확정적으로 막고, 301/302/307/308은 어떤 기준으로 고르며, 이미 캐시된 위험 링크의 철회와 Safe Browsing·관리자 abuse control을 어떻게 설명하겠습니까?”
읽기:쓰기와 cacheunique insertredirect cachetombstone + purge검사와 운영 제어 분리
SOURCES
공식·1차 출처
- IETF RFC 9110 — HTTP Semantics: redirect 상태 코드와 메서드 의미.
- IETF RFC 9111 — HTTP Caching: heuristic freshness와 `Cache-Control` 의미.
- Google for Developers — Safe Browsing: 위험 URL 신호 관련 공식 문서.
- IETF RFC 3986 — URI: Generic Syntax: URI 구문과 구성 요소.
NEXT CASE STUDY실시간 채팅 시스템 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- IETF, **RFC 9110 — HTTP Semantics**, redirect 상태 코드와 메서드 의미(§15.4): https://www.rfc-editor.org/rfc/rfc9110.html
- IETF, **RFC 9111 — HTTP Caching**, heuristic freshness와 `Cache-Control` 의미: https://www.rfc-editor.org/rfc/rfc9111.html
- Google for Developers, **Safe Browsing** 공식 문서: https://developers.google.com/safe-browsing
- IETF, **RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax**, URI 구문: https://www.rfc-editor.org/rfc/rfc3986.html
- 이 문서의 규모, 캐시 TTL, 상태 전이, 차단 기준은 학습용 설계 가정이다. 실제 도입 전에는 현재 공급자 약관, 브라우저·CDN 동작, 개인정보 법무 검토, 부하·장애 시험으로 검증한다.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.