자동 키와 사용자 alias를 같은 도메인 namespace에서 유일하게 관리합니다.
URL 단축 서비스
설계
짧은 문자열을 발급하는 것보다 이미 퍼진 링크를 되돌리는 일이 더 어렵습니다. 캐시·삭제·만료·악성 URL 차단이 같은 목적지를 보도록 회수 경계를 먼저 정합니다.
개념 이해리다이렉트 정책장애 대응운영 관점진도 저장
30초 핵심 요약
영구 redirect는 성능 옵션이 아니라 회수 가능성을 포기하는 약속입니다. 변경 가능한 링크는 302와 짧은 cache에서 시작하고, 삭제한 short key는 다른 목적지에 재사용하지 않아 오래된 캐시가 새 주소로 연결되지 않게 합니다.
키 발급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로 돕되, 이미 장기 저장된 영구 리다이렉트를 즉시 회수할 수 있다고 가정하지 않습니다.
짧은 링크의 목적지를 언제 영구로 약속할 것인가?
예시 새 링크
200만/day
설계 가정
예시 피크 읽기
약 34,700 req/s
계산 결과
Base62 7자 공간
약 3.52조
계산 결과
가변 링크는 302·짧은 캐시, 확정 링크만 301/308
목적지 변경·삭제 가능성이 있으면 302와 짧은 Cache-Control에서 시작합니다. 영구 redirect는 회수할 수 없음을 수용할 때만 사용하고 short key는 재사용하지 않습니다.
선택 이유
- 잘못된 목적지를 고쳐도 브라우저·프록시의 오래된 영구 캐시가 남는 위험을 줄입니다.
- 삭제·차단 뒤에도 과거 key가 새 목적지로 연결되는 보안 사고를 막습니다.
- 서비스 캐시와 HTTP redirect 캐시의 purge·TTL을 분리 관측할 수 있습니다.
모든 링크에 308과 긴 freshness 적용
캐시 효율은 높지만 목적지 오타·철회·정책 변경 뒤 서버가 기존 클라이언트의 이동을 즉시 회수할 수 없습니다.
감수한 단점
- 302와 짧은 TTL은 원본 redirect 서비스 요청을 늘립니다.
- 새 short key 교체는 배포 채널과 분석 연속성을 바꿉니다.
- 영구 정책은 실제 변경률과 삭제 약속을 먼저 검증해야 합니다.
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
# 트레이드오프리다이렉트 코드는 캐시 수명과 메서드에 관한 약속이다
301·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검사와 운영 제어 분리
답변 구조 보기 6단계
- 먼저 링크 생성/리다이렉트/관리, 공개 여부, 목적지 변경 가능성, 만료·삭제 SLA를 확인한다.
- 읽기:쓰기가 큰 예시를 세우고
domain + short_key캐시 우선 조회와 DB fallback을 제안한다. - Base62 순번 방식과 무작위 방식의 충돌·예측 가능성 차이를 설명한다. 무작위 방식은 반드시 unique insert로 확정한다고 말한다.
301/302/307/308의 캐시 기본값과 메서드 보존 차이를 말한 뒤, redirect cache는 즉시 회수할 수 없음을 명시한다.- alias·만료·삭제는 상태와 tombstone, purge, 짧은 TTL로 처리하고, 악성 URL 검사와 관리자 abuse control을 서로 다른 계층으로 제시한다.
- 마지막으로 cache hit ratio, purge lag, scan queue age, blocked/expired 응답, 비용과 오탐을 운영 지표로 연결한다. 이번 선택: 변경 가능성에 맞춰 redirect 상태와 캐시 수명을 함께 정한다. 깨지는 신호: DB 목적지와 실제 사용자 이동 목적지가 다르거나 purge lag가 TTL보다 길어진다. 다음 검증: 브라우저·프록시 캐시를 유지한 상태에서 목적지 변경·삭제·재생성을 시험한다.
잘못 캐시된 308을 회수할 수 없는 상황 설명하기
상태 코드 의미보다 목적지 변경 가능성과 캐시 수명을 먼저 답합니다.
- 가변 링크는 302와 명시적 짧은 TTL을 씁니다.
- 영구 redirect는 운영 약속이며 즉시 회수할 수 없음을 말합니다.
- 삭제된 short key를 재사용하지 않고 tombstone을 남깁니다.
브라우저·프록시 캐시를 유지한 채 변경·삭제를 검증합니다.
- DB 목적지와 실제 사용자 이동을 비교합니다.
- purge lag와 영구 cache hit를 관측합니다.
- 오류 링크는 새 key로 교체하고 구 key는 추적합니다.
TECHNICAL DOCUMENTS
기술 규격·공식 문서
- 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 구문과 구성 요소.
이 문제와 이어지는 문서대규모 웹 크롤러
리다이렉트와 URL 정규화를 함께 봅니다.
TECHNICAL DOCUMENTS & CONTACT
문의·정정
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.