실전 설계 사례 URL Shortener Notification Chat

실전 사례 설계는 유명한 구조를 외우는 일이 아니라 요구사항, 트래픽 모양, 정합성, 장애 허용 범위를 구체적인 선택으로 바꾸는 연습이다.
URL Shortener는 redirect read path와 key 충돌·abuse를, Notification은 fanout·retry·수신 거부를, Chat은 ordering·presence·fanout을, Feed는 timeline materialization을 대표한다.
같은 cache, queue, DB를 쓰더라도 사례마다 성능, 정합성, 장애 격리, 운영 복잡도 trade-off가 다르게 나타난다.

URL Shortener의 핵심 경로는 redirect다. 생성 API보다 read latency, cache hit, DB fallback, click log 비동기화가 중요하다.
Notification은 “보냈다”와 “도착했다”가 다르다. 수신 거부, channel preference, provider retry, DLQ, delivery tracking을 나눠야 한다.
Chat은 메시지 저장과 실시간 전달을 분리한다. ordering, duplicate, offline user, room size, presence의 owner를 정해야 한다.
Feed Timeline은 follower graph와 latency 요구에 따라 fanout on write, fanout on read, hybrid를 선택한다.
설계 리뷰는 컴포넌트 이름을 확인하는 것이 아니라 누락된 요구사항, 병목, 실패 모델, 관측 지표를 찾는 작업이다.

사용자 성공 기준을 기능별로 나눈다.
- Redirect 성공, 알림 접수, 메시지 저장, 피드 최신성은 서로 다른 성공이다.
읽기/쓰기 비율과 peak를 추정한다.
- URL redirect는 read-heavy, 알림과 피드는 fanout-heavy, 채팅은 room 크기에 민감하다.
동기 경로와 비동기 경로를 나눈다.
- 사용자 응답 전 필요한 작업과 나중에 처리 가능한 로그·알림·집계를 분리한다.
정합성 계약을 정한다.
- URL alias uniqueness, 알림 중복 허용 범위, chat ordering, feed staleness를 정한다.
장애 때 포기할 것을 정한다.
- click log, delivery tracking, read receipt, 추천/랭킹은 핵심 경로와 다르게 degrade할 수 있다.
운영 지표를 붙인다.
- redirect p95, delivery success, websocket connection, fanout lag, timeline freshness를 본다.

설계 사례를 정답 아키텍처로 외우기 쉽다.
- 같은 URL Shortener라도 private link, public marketing link, abuse 위험, analytics 요구에 따라 구조가 달라진다.
Queue를 넣으면 신뢰성이 생긴다고 오해하기 쉽다.
- Queue는 지연과 중복을 만든다. DLQ, idempotency, retry budget, replay 기준이 있어야 한다.
실시간 시스템은 WebSocket만 붙이면 된다고 느끼기 쉽다.
- 연결 상태, message ordering, 재전송, offline user, backpressure가 실제 설계의 핵심이다.
Feed는 단순 목록 조회라고 생각하기 쉽다.
- follower 수 편차와 유명인 hot key 때문에 write/read fanout 전략이 설계를 결정한다.

01. URL Shortener 설계 상세.md: short key 생성, redirect path, cache, abuse, click log를 다룬다.
02. Notification System 설계 상세.md: 수신자 선택, channel preference, retry, provider 장애, delivery tracking을 다룬다.
03. Chat System 설계 상세.md: message ordering, WebSocket, room fanout, presence, offline delivery를 다룬다.
04. Feed Timeline 설계 상세.md: fanout on write/read, celebrity account, freshness, materialized timeline을 다룬다.
05. 설계 리뷰와 개선 포인트 상세.md: 사례 설계안을 요구사항·병목·장애·운영 기준으로 다시 읽는 법을 다룬다.

확인 질문: 실전 사례 설계에서 먼저 고정할 것은 무엇인가?
- 답변: 사용자가 성공으로 느끼는 결과, peak traffic, 정합성 요구, 장애 때 포기 가능한 기능이다.
확인 질문: 같은 queue를 쓰더라도 알림과 피드에서 비용이 다른 이유는 무엇인가?
- 답변: 알림은 delivery와 retry가 중심이고, 피드는 follower graph와 timeline freshness가 중심이라 지연과 중복의 의미가 다르다.
확인 질문: 설계 리뷰에서 컴포넌트 그림보다 중요한 것은 무엇인가?
- 답변: 각 경계가 어떤 요구사항 때문에 생겼고, 실패하면 어떤 사용자 영향과 운영 지표로 드러나는지 설명하는 것이다.

동블