[0~5분]   요구사항 수집 및 범위 정의
[5~10분]  용량 추정 (Back-of-envelope calculation)
[10~20분] 고수준 설계 (High-level diagram)
[20~35분] 핵심 컴포넌트 상세 설계
[35~43분] 트레이드오프 논의 및 개선안 제시
[43~45분] 면접관 질문 대응

Vertical:   [Server 4GB RAM] → [Server 32GB RAM]
Horizontal: [Server] + [Server] + [Server] → Load Balancer 앞에 배치

사용자 → [가장 가까운 CDN 엣지] → (캐시 히트) → 콘텐츠 반환
                                 → (캐시 미스) → [Origin Server] → CDN 캐시 후 반환

1. 앱이 캐시에서 데이터 조회
2. 캐시 미스 → DB에서 조회
3. DB 결과를 캐시에 저장
4. 다음 요청부터 캐시 히트

1. 앱이 캐시에 쓰기
2. 캐시가 동기적으로 DB에도 쓰기
→ 데이터 일관성 보장, 쓰기 지연 발생

1. 앱이 캐시에만 쓰기
2. 캐시가 비동기적으로 DB에 쓰기
→ 쓰기 성능 우수, 캐시 장애 시 데이터 손실 위험

실무에서는 네트워크 파티션(P)은 피할 수 없으므로
  CP 시스템: 은행, 주식 거래 (일관성 우선)
  AP 시스템: SNS 피드, 쇼핑몰 장바구니 (가용성 우선)

링 구조 (0 ~ 2^32-1):

        0
       /|\
      / | \
Server A  Server B
    \   |   /
     Server C

키는 시계방향으로 가장 가까운 서버에 할당
서버 제거 시 해당 서버의 키만 다음 서버로 이동

Producer → [Message Queue] → Consumer

장점:
- 비동기 처리로 응답 시간 단축
- 트래픽 버퍼링 (트래픽 스파이크 흡수)
- 서비스 간 결합도 감소

쓰기 QPS:
  - 일 신규 URL 생성: 100M / 100 = 1M건/일
  - 초당 쓰기: 1,000,000 / 86,400 ≈ 12 QPS

읽기 QPS:
  - 읽기 = 쓰기 × 100 = 1,200 QPS
  - 피크: 1,200 × 5 = 6,000 QPS

Storage:
  - URL 레코드 1건 ≈ 500 bytes
  - 10년 데이터: 1M × 365 × 10 × 500 bytes ≈ 1.8 TB

Cache:
  - 80/20 법칙: 상위 20% URL이 80% 트래픽
  - 캐시 크기: 1,200 QPS × 86,400 × 0.2 × 500 bytes ≈ 10 GB/일

POST /api/v1/urls
  Request:  { "long_url": "https://example.com/...", "expire_date": "2027-01-01" }
  Response: { "short_url": "https://tinyurl.com/abc123" }

GET /{short_code}
  Response: 301 Redirect (영구) 또는 302 Redirect (임시)
  → 301: 브라우저 캐싱으로 서버 부하 감소 (분석 불가)
  → 302: 항상 서버 경유 (클릭 분석 가능)

문자셋: [0-9, a-z, A-Z] = 62개 문자
6자리 Base62 = 62^6 = 56.8억 가지 조합

long_url → MD5/SHA-256 → 처음 7바이트 추출 → Base62 인코딩 → 단축 코드

예시:
  "https://www.example.com/long-path"
  → MD5: "1a2b3c4d..."
  → 첫 7바이트의 정수값 → Base62 → "aB3xY9z"

CREATE TABLE url_mappings (
  id          BIGINT PRIMARY KEY,        -- Snowflake ID
  short_code  VARCHAR(8) UNIQUE NOT NULL,
  long_url    TEXT NOT NULL,
  user_id     BIGINT,
  created_at  TIMESTAMP DEFAULT NOW(),
  expire_at   TIMESTAMP,
  click_count BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON url_mappings(short_code);

[클라이언트]
    |
    v
[DNS] → [CDN] (정적 자원)
    |
    v
[Load Balancer]
    |
    +-----------+-----------+
    v           v           v
[API Server] [API Server] [API Server]
    |               |
    v               v
[Redis Cache]  [URL DB (Master)]
(단축 URL 캐싱)     |
                [URL DB (Replica)]
                (읽기 전용)

쓰기 흐름:
  클라이언트 → LB → API Server → DB 저장 → Redis 캐시 갱신 → 단축 URL 반환

읽기 흐름:
  클라이언트 → LB → API Server → Redis 캐시 확인
    → 캐시 히트: 즉시 리다이렉트
    → 캐시 미스: DB 조회 → Redis 저장 → 리다이렉트

트윗 작성 시:
  1. 트윗 DB에 저장
  2. 작성자의 모든 팔로워 ID 조회
  3. 각 팔로워의 타임라인 캐시(Redis)에 트윗 ID 삽입

장점: 읽기가 매우 빠름 (Redis에서 바로 조회)
단점: 팔로워 100M명 = 쓰기 100M번 → 쓰기 지연 큼

타임라인 조회 시:
  1. 사용자가 팔로우하는 계정 목록 조회
  2. 각 계정의 최신 트윗 조회 및 병합
  3. 시간 순 정렬하여 반환

장점: 쓰기가 단순
단점: 읽기 시 팔로우 수만큼 DB 쿼리 → 읽기 지연 큼

일반 유저 (팔로워 < 10,000):  Fan-out on write
셀럽 유저 (팔로워 >= 10,000): Fan-out on read

타임라인 생성:
  1. Redis에서 일반 유저들의 트윗 ID 조회 (Fan-out on write 결과)
  2. 팔로우 중인 셀럽의 최신 트윗 조회 (Fan-out on read)
  3. 두 결과를 병합 및 정렬

Key:   timeline:{user_id}
Value: Sorted Set (score = 트윗 timestamp, member = tweet_id)

예시:
  ZADD timeline:123 1700000001 tweet:456
  ZADD timeline:123 1700000002 tweet:789
  ZREVRANGE timeline:123 0 19  # 최신 20개 조회

최대 1,000개 트윗 ID만 유지 (메모리 관리)

64비트 구조:
  [1비트: 부호] [41비트: 타임스탬프] [10비트: 머신ID] [12비트: 시퀀스]

장점:
  - 시간 순 정렬 가능 (타임스탬프 포함)
  - 분산 환경에서 중복 없음
  - 초당 4,096개 × 머신 수만큼 생성 가능

[모바일/웹 클라이언트]
         |
    [API Gateway]
         |
   +-----------+
   |           |
[트윗 서비스] [타임라인 서비스]
   |                |
[트윗 DB]    [Redis 타임라인 캐시]
(Cassandra)          |
                [Fan-out 서비스]
                (Kafka 소비 후
                 팔로워 타임라인 갱신)
                     |
              [팔로워 그래프 DB]
              (팔로우 관계 저장)

미디어 처리:
[이미지/동영상 업로드] → [Object Storage (S3)] → [CDN]

[사용자]
   |
   v
[업로드 서비스] → S3 원본 저장
   |
   v
[메시지 큐 (Kafka)]
   |
   v
[트랜스코딩 워커들] (병렬 처리)
   ├── 360p 변환
   ├── 720p 변환
   ├── 1080p 변환
   └── 4K 변환
   |
   v
[CDN에 배포]
   |
   v
[메타데이터 DB 업데이트] → 사용자에게 완료 알림

사용자 네트워크 상태에 따라 자동으로 화질 변환:

[좋은 네트워크] → 1080p/4K 세그먼트 요청
[보통 네트워크] → 720p 세그먼트 요청
[나쁜 네트워크] → 360p 세그먼트 요청

HLS (HTTP Live Streaming) 방식:
  - 영상을 2~10초 세그먼트(.ts 파일)로 분할
  - M3U8 플레이리스트 파일로 세그먼트 목록 관리
  - 클라이언트가 주기적으로 버퍼 상태 확인 후 화질 결정

[Origin Server] → [Regional CDN] → [Edge CDN] → [사용자]

인기 동영상: 여러 엣지 노드에 사전 캐싱 (Push CDN)
비인기 동영상: 첫 요청 시 Origin에서 가져와 캐싱 (Pull CDN)

Netflix의 경우: ISP와 직접 협력하여 ISP 내부에 캐시 서버 배치 (OCA: Open Connect Appliance)

업로드 경로:
[크리에이터] → [업로드 API] → [S3] → [Kafka] → [트랜스코딩 클러스터]
                                                       |
                                                  [CDN 배포]

시청 경로:
[사용자] → [API Gateway] → [비디오 서비스]
                                  |
                    +-------------+-------------+
                    |             |             |
               [메타데이터]  [CDN 스트림]  [추천 엔진]
               (MySQL)      (HLS/DASH)   (ML 모델)

클라이언트 ←→ WebSocket 연결 ←→ Chat Server
  (지속적인 양방향 통신)

Cassandra 스키마:
  Partition Key: channel_id
  Clustering Key: message_id (Snowflake, 시간순 정렬)

  CREATE TABLE messages (
    channel_id  UUID,
    message_id  BIGINT,      -- Snowflake ID (시간 포함)
    sender_id   UUID,
    content     TEXT,
    created_at  TIMESTAMP,
    PRIMARY KEY (channel_id, message_id)
  ) WITH CLUSTERING ORDER BY (message_id DESC);

→ 채널별 최신 메시지 조회가 매우 효율적
→ 수평 확장 용이

메시지 상태: SENT → DELIVERED → READ

1. 메시지 전송 → DB에 상태 SENT 저장
2. 수신자 기기에 도달 → 상태 DELIVERED 업데이트 → 발신자에게 알림
3. 수신자가 메시지 확인 → 상태 READ 업데이트 → 발신자에게 알림

방법 1: Heartbeat (30초마다 서버에 핑)
  - Redis에 user:{id}:last_seen = timestamp 저장
  - TTL 60초 설정 → 60초 이상 핑 없으면 오프라인

방법 2: WebSocket 연결 상태 추적
  - 연결 시 온라인, 연결 해제 시 오프라인 이벤트 발생
  - 친구들에게 상태 변경 Pub/Sub으로 전파

소규모 그룹 (N < 100):
  [발신자] → [Chat Server] → [각 멤버에게 직접 WebSocket 전송]

대규모 그룹 (N >= 100):
  [발신자] → [Chat Server] → [Kafka Topic: group:{id}]
                                    |
                              [Consumer 클러스터]
                                    |
                         [각 멤버 기기로 푸시 알림]

WhatsApp의 Signal Protocol 기반:
  1. 각 기기에서 공개키/비밀키 쌍 생성
  2. 서버에 공개키만 등록
  3. 발신자: 수신자 공개키로 메시지 암호화
  4. 서버: 암호화된 메시지만 전달 (내용 해독 불가)
  5. 수신자: 자신의 비밀키로 복호화

읽기 확장:     Master-Slave 복제 + 읽기 전용 Replica
쓰기 확장:     Sharding (Consistent Hashing)
캐싱:          Redis (인메모리) → DB 부하 감소
검색:          Elasticsearch → 전문 검색
시계열 데이터: InfluxDB / TimescaleDB
그래프 데이터: Neo4j / Amazon Neptune

작업 큐:  무거운 작업(트랜스코딩, 이메일 발송) 비동기 처리
이벤트 스트리밍: Kafka → 서비스 간 이벤트 전파
CQRS: 읽기/쓰기 모델 분리로 성능 최적화
Saga 패턴: 분산 트랜잭션 처리