트위터 / X (Twitter Clone)

이 스키마에 대하여

눈여겨볼 관계

tweets → tweets (두 번)

reply_to_id 와 quote_tweet_id 는 서로 다른 자기참조입니다. 둘 다 null 이면 원본 트윗이고, 둘이 동시에 채워지는 일은 없습니다.

tweets → retweets

리트윗은 트윗이 아니라 여기의 한 행입니다. "이 사용자의 트윗" 질의가 본문 없는 행을 걸러낼 필요가 없어지고, 리트윗 취소가 삭제 한 번이 됩니다.

hashtags → trending_topics

지역별로 started_at·ended_at 과 함께 남깁니다. 현재 상태 테이블이 아니라 기록이라, 어제 무엇이 트렌드였는지도 답할 수 있습니다.

notifications → users (두 번)

recipient_id 는 보는 사람, actor_id 는 일으킨 사람입니다. 둘 다 들고 있어야 누가 무엇을 했는지 다시 캐지 않고 알림을 그릴 수 있습니다.

blocks → users (두 번)

blocker_id 와 blocked_id 로 방향이 있습니다. 차단은 상호가 아니고, 방향이 누구의 타임라인에서 무엇을 숨길지 정합니다.

설계 판단

자주 묻는 것

리트윗을 그냥 트윗으로 두면 안 되나요?

본문이 없기 때문입니다. 본문이 null 인 트윗은 모든 타임라인 질의가 "이걸 글로 그릴까 지지로 그릴까" 를 판단해야 하고, 리트윗 취소가 사용자에게는 글로 보이던 것의 삭제가 됩니다. 따로 두면 좋아요처럼 동작하는데, 실제로 그런 것입니다.

reply_to_id 와 quote_tweet_id 가 동시에 채워질 수 있나요?

그러면 안 됩니다 — 답글이거나 인용이지 둘 다일 수 없습니다. 스키마가 막고 있지는 않으니, 가정이 아니라 보장으로 두고 싶으면 체크 제약을 거세요.

likes 테이블이 있는데 like_count 를 왜 저장하나요?

타임라인 한 장이 트윗 수십 개를 그리고 각각에 숫자를 붙입니다. 트윗마다 likes 를 세는 질의는 인기 계정을 만나는 순간 버티지 못합니다. 테이블이 여전히 진실이라 카운터는 다시 만들 수 있습니다 — 대체가 아니라 맞춰 주는 작업이 딸린 캐시입니다.

차단은 어떻게 적용되나요?

스키마가 하지 않습니다. blocks 는 방향을 적을 뿐이고, 타임라인·알림·DM 을 거르는 것은 애플리케이션입니다. DB 에서 하려면 모든 읽기가 blocks 와 조인해야 해서, 보통은 사용자별로 캐시한 집합을 씁니다.

스레드는 어떻게 구성되나요?

reply_to_id 를 거슬러 올라가 null 인 트윗까지 가거나, 거기서 내려오는 사슬입니다. 긴 스레드를 재귀 CTE 로 읽어도 되지만, 대개는 트윗에 대화 루트를 같이 저장해서 스레드 전체를 인덱스 조회 한 번으로 가져옵니다.