🔗 Bit.ly 시스템 설계

긴 URL을 짧은 링크로 변환하는 URL 단축 서비스

🤔 왜 URL 단축 서비스가 필요한가?

문자 수 제한

• 트위터, SMS 등 글자 수 제한이 있는 플랫폼에서 유용
• 긴 URL이 공간을 많이 차지하는 문제 해결

가독성 향상

• 짧고 간결한 링크로 공유가 쉬움
• 보기 좋고 기억하기 쉬운 URL 생성

링크 관리

• URL 클릭 수, 지역, 시간 등 분석 가능
• 만료 기한 설정으로 임시 링크 관리
• 커스텀 별칭으로 브랜딩 가능

보안 및 신뢰

• 원본 URL을 숨겨 스팸이나 악성 링크 차단
• 링크 미리보기 기능으로 안전성 확인

---

📋 기능 요구사항

URL 단축

• 긴 URL 입력 → 짧은 URL 생성
• 예: https://www.example.com/very/long/url/path → bit.ly/abc123

커스텀 옵션

• 사용자 지정 별칭 설정 가능
• URL 만료 기한 설정 가능

리디렉션

• 짧은 URL 접속 시 원본 URL로 자동 이동

---

📊 시스템 규모

• 총 단축 URL: 10억 개 (10B)
• 일일 활성 사용자: 1억 명 (100M)

---

🔍 계략치 추정

TPS (Transactions Per Second)

가정

• 1억 명의 유저 (10^8)
• 하루에 10번 request
• Read:Write 비율 = 9:1
• 하루 ≈ 10^5 초

계산

총 request = 10^8 × 10 = 10^9 request/일

쓰기 TPS = (10^9 × 0.1) / 10^5 = 1,000 TPS
읽기 TPS = (10^9 × 0.9) / 10^5 = 9,000 TPS

저장용량

💡 Base64의 +와 /는 URL에서 특수 문자로 사용되므로 제외한 62개 문자(0-9, a-z, A-Z) Base62로 인코딩합니다.

단축 URL 저장

• Base62 인코딩: 6자 필요
• 10^9 개 URL × 6 bytes = 6GB

메타데이터 포함

• 원본 URL, 생성일, 만료일, user_id 등
• 레코드당 약 200 bytes
• 10^9 개 × 200 bytes = 200GB

요약

항목	값
쓰기 TPS	1,000 TPS
읽기 TPS	9,000 TPS
단축 URL 저장	6GB
총 저장용량	200GB

---

📋 비기능 요구사항

Scalability & CAP

분산 처리

• 수평적 확장(Horizontal Scaling) 지원
• 다중 서버 구성으로 트래픽 분산

CAP 정리

• AP 우선 (Availability + Partition Tolerance)
• Eventual Consistency 허용
• 고가용성을 통한 서비스 안정성 확보

응답 시간 목표

작업 유형	목표 응답 시간
리디렉션 (읽기)	< 100ms
URL 생성 (쓰기)	< 200ms

P99 Latency

• 리디렉션: < 200ms
• URL 생성: < 500ms

---

🗄️ 도메인 모델

URL

Column	Type	Description	Constraints
id	BIGINT	Primary key, auto-increment	PRIMARY KEY
short_url	VARCHAR(10)	Shortened URL code (e.g., "abc123")	UNIQUE, NOT NULL, INDEX
original_url	TEXT	Original long URL	NOT NULL
user_id	BIGINT	User who created the URL	NULLABLE, INDEX
created_at	TIMESTAMP	Creation timestamp	NOT NULL, DEFAULT NOW()
expires_at	TIMESTAMP	Expiration timestamp	NULLABLE, INDEX
click_count	INT	Number of times accessed	DEFAULT 0
is_deleted	BOOLEAN	Whether URL is deleted	DEFAULT FALSE
is_custom	BOOLEAN	Whether short_code is custom	DEFAULT FALSE

---

🔌 API 설계

1. URL 생성

POST /api/urls
Content-Type: application/json

Request

{
  "original_url": "https://www.example.com/very/long/url/path",
  "alias": "my-custom-link",  // optional
  "expires_at": "2025-12-31"  // optional
}

Response

201 Created

{
  "short_url": "https://bit.ly/abc123",
  "original_url": "https://www.example.com/very/long/url/path",
  "expires_at": "2025-12-31T23:59:59Z"
}

---

2. URL 리디렉션

GET /{short_code}

Response

302 Found
Location: https://www.example.com/very/long/url/path

---

요약

Method	Endpoint	Description
POST	/api/urls	Create shortened URL
GET	/{short_code}	Redirect to original URL

---

🏗️ 시스템 아키텍처

전체 구조

처음 설계한 시스템 구조는 위와 같습니다. 기본적인 Load Balancer, API Servers, Redis Cache, 그리고 Database로 구성되어 있습니다.

이 구조에서는:

• Load Balancer가 트래픽을 API Server들로 분산,
• API Server가 Redis Cache와 Database를 직접 참조,
• 단순하고 명확한 구조로 빠른 구현 가능합니다.

위 구조에서도 충분히 트래픽을 감당할 수 있겠지만 보다 더 명확하게 읽기/쓰기라는 관심사를 분리 또 독립적으로 확장하기 위해서는 아래와 같이 개선 될 수 있을 것입니다:

발전된 구조의 핵심 개선사항:

• Write Servers와 Read Servers의 명확한 분리: 쓰기와 읽기 워크로드가 독립적으로 스케일 가능
• Database Replication 도입: Primary DB(쓰기)와 Read Replicas(읽기) 분리로 DB 부하 분산
• 더 정교한 캐싱 전략: Read Server가 Redis와 Read Replicas를 효율적으로 활용

주요 컴포넌트

1. Load Balancer (로드 밸런서)

역할

• 클라이언트 요청을 여러 API 서버로 분산
• 서버 헬스 체크 및 장애 감지
• SSL 종료 처리

라우팅

POST /api/urls → Write Servers
GET /{shortCode} → Read Servers

---

2. API Servers

Write Servers (쓰기 서버)

• URL 생성 요청 처리
• Primary DB에 데이터 저장
• 목표: 1,000 TPS

Read Servers (읽기 서버)

• 리디렉션 요청 처리
• Redis 캐시 우선 조회
• 목표: 9,000 TPS

---

3. Redis Cache (캐싱 계층)

역할

• Hot URLs (자주 접근되는 URL) 캐싱
• 90%+ 요청을 1-5ms에 처리
• DB 부하 대폭 감소

캐시 전략

Key: url:{short_code}
Value: {original_url}
TTL: 24시간

---

4. Database

Primary DB (Master)

• 모든 쓰기 작업 처리
• 단일 진실 공급원

Read Replicas (읽기 복제본)

• Cache miss 시 읽기 처리
• Primary DB 부하 분산
• 비동기 복제로 동기화

---

데이터 흐름

읽기 요청 (리디렉션)

1. Client → Load Balancer
2. Load Balancer → Read Server
3. Read Server → Redis Cache
   ├─ Cache Hit → 즉시 응답 (1-5ms)
   └─ Cache Miss → Read Replica 조회 (50ms)
4. 원본 URL로 302 리디렉션

---

쓰기 요청 (URL 생성)

1. Client → Load Balancer
2. Load Balancer → Write Server
3. Write Server → Primary DB 저장
4. Write Server → Redis Cache 저장 (선택)
5. Primary DB → Read Replicas 복제 (비동기)
6. 단축 URL 응답

---

성능 최적화

캐싱

• 90%+ 요청을 Redis에서 처리
• 응답 시간 < 5ms

DB Replication

• 읽기 부하를 여러 Replica로 분산
• 수평 확장 가능

로드 밸런싱

• 트래픽을 여러 서버로 분산
• 고가용성 보장

---

확장성

수평 확장

• API 서버 추가로 TPS 증가
• Read Replica 추가로 읽기 성능 향상

고가용성

• 다중 서버로 단일 장애점 제거
• 장애 시 자동 페일오버

성능

• 캐싱으로 빠른 응답
• DB 부하 최소화

---

🤖 단축 URL 알고리즘

방법 1: Hash 함수

프로세스

원본 URL
  ↓
Hash 함수 (MD5/SHA256)
  ↓
앞 X자 추출
  ↓
16진수 → 10진수 변환
  ↓
Base62 인코딩
  ↓
충돌 검사
  ├─ 충돌 없음 → 저장
  └─ 충돌 발생 → 랜덤 값 추가 후 재시도
  

장점

✅ 같은 URL은 항상 같은 단축 코드
✅ 분산 환경에 적합
✅ 구현 간단

단점

❌ 충돌 가능성 존재
❌ 충돌 시 재시도 필요
❌ 예측 불가능한 응답 시간

방법2 counter + BASE62 Encoding

프로세스

요청
↓
Counter에서 고유 ID 발급
↓
Base62 인코딩
↓
저장 (충돌 없음!)

성능

Redis INCR 성능: 100,000+ ops/sec
10,000 TPS 요구사항: ✅ 충분히 가능

장점

✅ 충돌 절대 없음
✅ 빠른 성능
✅ 예측 가능한 응답 시간

단점

⚠️ 순차적이라 예측 가능
⚠️ Redis가 단일 장애점 (Redis Cluster로 해결가능)

ID 배치로 받아올 때의 Trade-off

👍 성능 개선

Redis 호출 1/N 감소
로컬 메모리에서 즉시 할당

👎 비용

ID 낭비 (서버 장애 시 미사용 ID 손실)
메모리 사용량 증가
ID 순서에 Gap 발생

⚖️ 배치 크기가 핵심: 100~1000개 권장

---

📚 참조

가상 면접 사례로 배우는 대규모 시스템 설계 기초
Hello Interview