v3

v3 - 비동기 피드 생성

• 게시물에 대한 쓰기 성능이 감소한다 → 비동기 작업으로 극복할 수 있다
• 비동기 작업 시 피드 반영이 늦을 수 있다 → 비즈니스 특성 상 실시간성이 중요하지는 않으며, 사용자는 체감이 어려울 것이다

What's Changed

• feat(feed): 사용자가 게시물을 작성하면 게시물 작성 이벤트가 발행된다 by @siyeonSon in #12
• test: 테스트를 격리한다 by @siyeonSon in #14

Full Changelog: v2...v3

v2

v2 - 사전 생성된 피드

• 사용자의 피드를 미리 생성해두고, 팔로우하는 사용자의 새 게시물을 피드에 추가한다
  1. 사용자 A는 사용자 B를 팔로우한다
  2. 사용자 B가 게시물을 작성하면 팔로워(A)들의 피드에 해당 게시물을 삽입한다
  3. 사용자 A가 피드를 조회한다
• 장점: 피드 조회 비용이 저렴하다
  • 시간복잡도 ↓, 팔로잉 수 및 게시물 수에 영향받지 않는다
• 단점:
  • 게시물에 대한 쓰기 성능이 감소한다
  • 비동기 작업 시 피드 반영이 늦을 수 있다
  • 포스팅 5만개 사용자 1만명이라 가정하자
    • 사용자마다 팔로우를 100명씩 한다고 하더라도 Feed 테이블 컬럼 수가 최소 10만은 넘을 것이다
    • 따라서 DB 성능 상 무리가 있을 것이다 → DB index를 사용하면 무리가 줄어들 것이다

What's Changed

• feat: 사전 생성된 피드를 사용한다 by @0chil in #10
• refactor(follow): primitive long을 걷어낸다 by @0chil in #11

Full Changelog: v1...v2

v1

v1 - 온디맨드 피드

• 사용자 요청이 있을 때마다 피드를 생성한다
  1. 사용자 A의 팔로우 목록(팔로잉)을 가져온다
  2. 팔로우하는 사용자(팔로잉)들의 게시물들을 가져온다
  3. 게시물들을 모아 피드로 보여준다
• 단점: 쿼리가 복잡하며 조회 비용이 크다
  • 시간복잡도 ↑, (팔로잉 수 * 팔로우하는 사용자의 게시물 수)에 지수적 영향을 받는다

What's Changed

• refactor: 패키지 구조 수정 by @0chil in #1
• feat: 사용자 게시물 작성 by @siyeonSon in #2
• feat(follower): 다른 사용자를 팔로우 할 수 있다 by @0chil in #3
• feat(feed): 사용자의 피드를 조회한다 by @siyeonSon in #4
• refactor(follow): reference type -> primitive type 사용 by @siyeonSon in #5
• test: 박싱과 언박싱 성능 실험 by @0chil in #6
• refactor(follow): 팔로우 영속화 by @0chil in #7
• feat(study): 레퍼런스 타입과 원시 타입 박싱 학습 테스트 보완 by @0chil in #8
• docs: readme 작성 by @siyeonSon in #9

Full Changelog: https://github.com/siyeonSon/feed-system-design/commits/v1