Hacker News 의견

• 시스템 애호가로서 이런 기사를 즐기는 사람임. "완벽해야 한다"는 사고방식에 빠지기 쉬움

  • Blekko 검색 엔진의 백엔드에서 '결국 일관성 있는' 인덱스를 구축했음. 이는 사용자에게 더 빠르게 업데이트를 제공하지만, 동일한 쿼리를 수행하는 두 사용자가 약간 다른 결과를 얻을 수 있음
  • 시스템 이론이 많이 적용되며, 긍정적인 피드백이 있을 경우 진동할 가능성이 있음. 검색 엔진에서는 사용자가 클릭한 링크에 가중치를 부여하는 랭커가 긍정적인 피드백을 제공함
  • 시스템이 "비판적으로 감쇠"되도록 유지하는 것이 중요했음. 이는 빠르게 수렴하도록 함
  • 사용자의 타임라인이 샤딩되고 피드백 루프(예: '좋아요'나 '리포스트')가 있는 방식이 흥미로운 문제 공간으로 보임

• 타임라인을 계정의 인기도에 따라 하이브리드 방식으로 구현하지 않는 이유가 궁금함

  • 유명인 계정의 경우, 모든 메시지를 수백만 명의 팔로워에게 퍼뜨리는 대신, 팔로워의 타임라인을 제공할 때 유명인의 게시물을 가져와 병합하는 것이 더 저렴할 것임
  • 수백만 명의 팔로워가 그렇게 하면, 핫 캐시에서 읽기 전용으로 가져오는 것이 저렴할 것임

• 흥미로운 문제에 대한 흥미로운 해결책임. 공유해줘서 고마움

  • 저자가 "유명인"에서 "봇"으로 전환하는 부분을 이해하는 데 어려움이 있었음
  • 저자는 "손실 타임라인"이라는 완전히 다른 개념을 도입한 것처럼 보였음

• 일관성을 희생하는 이 전략에 대해 궁금함. 읽기나 쓰기에서 완전한 팬아웃이 아닌 다른 방법에 대한 생각이 있는지 궁금함

  • 모든 사용자의 타임라인에 쓰는 대신, 적어도 한 명의 팔로워가 있는 샤드에 한 번만 쓰는 방법을 상상해봄
  • 읽기 시, 주어진 사용자의 콘텐츠를 가져와 실제 팔로워를 필터링함
  • 읽기가 샤드 내에 위치하므로 지연 시간이 낮음
  • 메가 팔로워의 경우 페이지가 오래된 항목을 보지 않음

• 모든 사용자가 팔로우하는 수천 명의 사용자가 게시한 모든 것을 완벽하게 시간순으로 제공할 필요는 없지만, 타임라인에 항상 새로운 콘텐츠가 있도록 충분한 콘텐츠를 제공하는 것이 합리적임

  • 해결책이 불완전한 시간순서가 아니라 피드에서 게시물이 누락된 것처럼 보였음

• 핫 샤드 문제를 피하기 위해 팔로워 수를 제한하는 것이 어떻게 작동할지 궁금함

  • 각 사용자는 1000명의 팔로워마다 별도의 타임라인을 가지며 클라이언트가 이를 병합함
  • 필요하다면 실제 타임라인의 일부만 로드하여 손실 부분을 수행할 수 있음

• AWS는 이 문제에 대한 멋진 일반적인 접근 방식을 가지고 있음

  • 각 사용자를 여러 샤드에 할당하여 다른 사용자가 모든 샤드를 공유할 가능성을 줄임
  • 처음부터 셔플 샤딩을 했다면 많은 다른 사용자에게 영향을 주지 않고 새로운 문제를 해결할 수 있었을 것임

• 수십만 명의 사용자를 팔로우하는 계정은 콘텐츠를 긁어모으는 봇 계정임이 분명함. 차단하고 끝내겠음

  • 기술적 도전에 대해 읽는 것을 좋아함. Twitter는 수백만 명의 팔로워를 가진 유명인을 위한 특별한 아키텍처를 가지고 있음
  • Bluesky가 유사한 클론이라면 왜 이를 따르지 않았는지 궁금함

• 사용자의 프로필로 직접 이동하여 모든 게시물을 볼 때, 타임라인에 있어야 할 게시물이 없는 경우가 있음

  • Bluesky에서 100명 미만의 사용자를 팔로우하지만, 가끔 타임라인에서 사용자의 게시물을 보지 못하는 이유를 설명함

• 각 "페이지"가 다음 페이지를 가져오는 것을 차단하는 방식으로 팬아웃을 구현한 이유가 궁금함

  • 페이지 가져오기 활동은 연속적으로 팔로워를 가져와야 하며, 페이지의 모든 항목이 업데이트될 때까지 기다리지 않아야 함
  • 페이지를 가져와 S3에 저장하고 메타데이터와 S3 위치를 큐(SQS)에 게시하는 가져오기 구성 요소를 가지는 것이 떠오름
  • 이 시스템에서 동시성을 더 잘 제어할 수 있으며, 샤드를 키로 사용하여 큐에서 파티셔닝하여 작업을 "느리게" 할 수 있음