시스템 디자인
사례 연구 / 콘텐츠·검색 / News Feed
학습 로드맵
CASE · ADVANCED읽기 24분검토일 2026-08-29

뉴스 피드 시스템
설계

피드는 단순히 게시물을 모으는 목록이 아닙니다. 누구에게 미리 복사할지, 언제 읽어 합칠지, 무엇을 먼저 숨길지, 랭킹이 멈춰도 무엇을 보여 줄지를 함께 결정하는 개인화 시스템입니다.

개념 이해fan-out 전략장애·철회면접 답변진도 저장
30초 핵심 요약

hot 작성자는 팔로워 수가 아니라 예상 inbox 쓰기량과 queue age로 전환합니다. 전환과 롤백 임계값을 다르게 두고 source watermark와 post ID로 이행 구간의 중복·누락을 막습니다.

일반 작성자write fan-out
hot 작성자read fan-out
철회 안전성정본 필터 + tombstone
DESIGN DECISION · 설계 판단

hot 작성자를 어떤 수치로 전환하고 언제 되돌릴 것인가?

예시 DAU 5,000만 명 설계 가정
예시 피드 읽기 4억/day 계산 결과
hot 작성자 100만+ 팔로워 설계 가정
최종 선택

쓰기량·queue age 기반 hybrid fan-out + hysteresis

예상 inbox 쓰기가 2,000/s를 5분 넘거나 queue age가 15초를 넘으면 read fan-out으로 전환합니다. 800/s 미만 30분과 backlog 0을 확인한 뒤에만 원복합니다.

선택 이유

  • 팔로워 수 하나보다 게시 빈도와 실제 queue 지연을 함께 반영합니다.
  • 전환·롤백 임계값을 달리해 경계에서 정책이 반복 진동하는 일을 막습니다.
  • source watermark와 post ID 중복 제거로 이행 중 누락·중복을 제한합니다.
포기한 대안

팔로워 수 임계값 하나로 즉시 양방향 전환

게시 빈도와 큐 상태를 놓치고 경계 근처 작성자가 write/read fan-out을 반복해 캐시·backlog를 흔듭니다.

감수한 단점

  • 읽기 경로가 inbox와 author timeline을 함께 병합해야 합니다.
  • 전환 중 두 source에 같은 post가 존재할 수 있습니다.
  • 임계값은 follower 분포·게시 빈도·인프라 비용을 실측해 조정해야 합니다.
01 · REQUIREMENTS

빠른 목록보다 안전한 노출 경계를 먼저 정한다

# 요구사항

홈 피드는 작성·팔로우·차단·삭제처럼 서로 다른 정본을 만납니다. inbox의 빠른 후보와 실제 열람 권한을 같은 것으로 취급하지 않습니다.

R1개인화 후보

팔로우한 작성자·그룹·추천 source를 분리해 후보를 만들고 post ID로 합칩니다.

R2안정적 페이지

불투명 cursor와 정렬 snapshot으로 새 post가 들어와도 스크롤 중복을 줄입니다.

R3권한 철회

삭제·차단·언팔로우·공개 범위 변경은 다음 응답에서 숨길 수 있어야 합니다.

R4안전 fallback

ranker나 feature가 실패해도 정책 필터를 거친 시간순 후보를 제한적으로 보입니다.

02 · HIGH-LEVEL DESIGN

post 정본, graph, 후보 inbox, ranker를 분리한다

# 아키텍처

post 저장과 outbox 기록은 같은 쓰기 경계에서 확정하고, fan-out·색인·랭킹 feature는 재시도 가능한 소비자로 분리합니다. 읽기에서는 hot timeline과 inbox 후보를 합친 뒤 정책을 먼저 확인합니다.

hybrid fan-out의 쓰기와 읽기 경로 SVG DIAGRAM · candidate → policy filter → rank
뉴스 피드의 hybrid fan-out 아키텍처작성자의 게시물이 post 저장소와 outbox를 거쳐 일반 follower의 inbox와 hot 작성자의 timeline으로 전달되고, 독자 요청이 후보를 병합하여 정책 필터와 랭커를 거쳐 피드를 받는 흐름이다.쓰기 · post 생성과 비동기 fan-out읽기 · 후보 병합과 권한 필터Post APIidempotency · visibilityPost + Outboxauthor sequenceFan-out workerbatch · retry · dedupeAuthor timelinehot writer read sourceFeed inboxnormal writer candidatesFeed APImergePolicyblock · deleteRankfreshnessinbox는 재구축 가능한 후보이다. 삭제·privacy는 정본 정책으로 다시 확인한다.
설계 경계: hot 작성자의 기준은 팔로워 수 하나가 아니라 최근 fan-out write, queue lag, 활성 독자, timeline cache hit을 함께 보는 정책입니다. 전환 중에는 두 경로가 겹칠 수 있으므로 read-time post_id 중복 제거가 필요합니다.
03 · WRITE / READ FLOW

쓰기에는 후보를, 읽기에는 정책과 순위를 둔다

# 흐름
1원자적 post + outbox

작성 ACK 전에 post 정본과 전파 이벤트가 함께 기록되어 유실 창을 줄입니다.

2일반 write fan-out

follower 배치에 post ID를 멱등 upsert해 개인 inbox 후보를 만듭니다.

3hot read fan-out

수백만 inbox write 대신 author timeline 하나를 기록해 읽을 때만 합칩니다.

4권한·철회 필터

block, mute, audience, 삭제, tombstone을 ranker 앞에서 제거합니다.

5랭킹과 cursor

신선도·관계 feature로 정렬하고 세션 안정성을 위한 snapshot cursor를 돌려줍니다.

04 · TRADEOFFS

평균이 아니라 긴 꼬리와 철회 비용을 비교한다

# 트레이드오프

fan-out 전략은 랭킹 여부와 별개입니다. 어떤 전략이든 후보는 중복될 수 있고, 삭제·차단·공개 범위 변경은 최종 노출 전에 확인해야 합니다.

선택강점제약적용 판단
fan-out on write개인 inbox 읽기가 빠르고 단순팔로워 수만큼 queue·저장 write가 증가일반 작성자, 높은 읽기 빈도
fan-out on readpost는 한 번 기록, write 폭발 방지feed 열기 때 timeline 병합·hydrate 비용매우 큰 follower를 가진 hot 작성자
hybrid긴 꼬리 비용을 제한경계, 이행, dedupe, 관측이 복잡팔로워 분포가 크게 치우친 서비스
시간순 fallback설명·복구·디버깅이 쉬움관련성·다양성 최적화가 제한ranker 장애, 초기 제품
inbox에 post ID삭제·수정·privacy를 정본에서 확인read-time hydrate 필요철회 요구가 중요한 피드
05 · FAILURE MODES

지연·중복·철회를 측정 가능한 복구 절차로 만든다

# 장애 6가지
fan-out 큐 적체

새 post가 follower inbox에 늦어져 작성 시각과 노출 시각이 크게 벌어집니다.

대응 · consumer 확장, 배치 축소, hot 정책 전환. post-to-inbox delay가 SLA 안인지 검증합니다.
hot 작성자 폭주

한 post가 수백만 inbox write를 만들어 일반 작성자까지 밀어냅니다.

대응 · dynamic read fan-out, 전용 quota와 cache. 일반 writer lag 회복을 확인합니다.
중복·순서 뒤집힘

at-least-once 재시도나 이행 구간에서 같은 카드가 두 번 보일 수 있습니다.

대응 · (viewer, post) 멱등 upsert, read dedupe, source watermark. duplicate 0을 표본 검사합니다.
랭킹 서비스 장애

feature 지연·모델 오류가 빈 피드나 높은 p99로 이어집니다.

대응 · 정책 필터를 거친 최근성 fallback과 circuit breaker. fallback 비율을 관측합니다.
×삭제·privacy 철회 지연

stale inbox와 cache에 삭제·차단된 post가 잠시 남습니다.

대응 · 정본 상태 확인, tombstone push, purge 재시도. revoke-to-hide 시간을 검증합니다.
!graph shard 실패

팔로우·block 정책을 읽지 못해 노출 판단이 불명확해집니다.

대응 · fail-closed 범위, 짧은 권한 cache, 재시도. policy version 일치와 오노출 0을 확인합니다.
06 · OPERATIONS

보안·관측·비용을 후보 생성 밖에서 운영한다

# 운영
보안·개인정보

cursor를 viewer·정책 버전에 결속하고, 권한 필터를 ranker보다 먼저 둡니다. 관계 그래프·본문·feature는 최소 권한과 보존 기간으로 접근합니다.

block · audience · tombstone
관측 가능성

fan-out lag, candidate shortage, hot merge, ranker fallback, duplicate, revoke-to-hide를 author·source·policy 차원으로 제한해 관측합니다.

revoke_to_hide_seconds
비용 모델

inbox write·복제·TTL, timeline merge, post hydrate, feature read, purge와 고카디널리티 로그가 비용을 만듭니다. hit ratio 하락은 origin read를 급증시킵니다.

fanout writes × replica × TTL
면접 모드 · 추가 질문06:00
“팔로워가 수백만 명인 계정과 일반 계정이 함께 있는 뉴스 피드를 설계해 보세요. fan-out on write/read를 어떻게 조합하고, 랭킹 신선도·중복·삭제·privacy 철회를 장애 상황에서도 어떻게 보장하겠습니까?”
hybrid 경계와 관측outbox + 멱등 fan-out정책 필터 우선시간순 fallbacktombstone + purge
답변 구조 보기 6단계
  1. 홈 피드 범위, 시간순/랭킹, 최대 팔로워 수, 삭제·차단 SLA, 광고·추천 포함 여부를 먼저 확인한다.
  2. post·graph·feed inbox를 정본과 파생 데이터로 구분하고, post 저장과 outbox 기록을 원자화한다.
  3. 일반 작성자에는 fan-out on write, hot 작성자에는 fan-out on read를 쓰는 hybrid 정책과 그 경계의 관측 지표를 설명한다.
  4. 읽기에서 inbox·timeline 후보를 합치고 권한·삭제 필터를 ranker보다 먼저 적용한다고 말한다.
  5. 큐 적체, hot user, 중복, ranker 장애, 삭제/privacy 철회 지연, graph 실패를 감지·대응·복구 검증까지 연결한다.
  6. 마지막으로 revoke_to_hide_seconds, fan-out lag, candidate shortage, fallback ratio, 비용과 feature privacy를 운영 지표로 제시한다. 이번 선택: hot 전환과 롤백에 서로 다른 임계값과 유지 시간을 둔다. 깨지는 신호: 정책이 경계에서 반복 전환되거나 두 source 병합에서 duplicate·gap이 늘어난다. 다음 검증: 9,000 writes/s 버스트 뒤 backlog drain과 800/s 롤백을 순서대로 재현한다.
INTERVIEW ↔ PRACTICE · 면접과 실무의 차이

18만 팔로워·분당 3개 게시물을 read fan-out으로 전환하기

INTERVIEW · 면접

예상 쓰기량과 queue age로 전환·롤백을 계산합니다.

  • 18만×3÷60으로 약 9,000 writes/s를 계산합니다.
  • 2,000/s·15초 조건에서 hot 정책을 전환합니다.
  • 800/s 30분·backlog 0에서만 원복합니다.
PRACTICE · 실무

두 source 병합과 경계 진동을 부하 시험합니다.

  • post ID dedupe와 watermark gap을 관측합니다.
  • 일반 작성자의 post-to-inbox 지연 회복을 확인합니다.
  • 버스트 뒤 backlog drain과 hysteresis를 재현합니다.
SOURCES

공식·1차 출처

NEXT CASE STUDY검색 자동완성 설계
EDITORIAL NOTES

작성·검토·참고 자료

콘텐츠 원칙
이 문서는 독립적으로 재작성한 한국어 학습 자료입니다. 사실과 학습용 설계 가정을 구분합니다.
작성·기술 검수
프로젝트 운영자가 직접 작성·기술 검토했습니다. 주제별 공식·1차 자료와 명시적인 설계 가정을 확인하며, 독립적인 제3자 검수가 아닙니다. 경력 범위와 검수 원칙 보기
최종 검토
예상 학습 시간
24분

사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.