Design Message Threads - System Design | WinJob

Design Message Threads — product and timeline context

Message threads let users branch a conversation off a parent post while keeping the main channel timeline readable. Slack, Discord, and Twitter/X each expose threads differently, but the backend invariant is the same: a directed tree anchored at a thread root with monotonic ordering inside the branch and optional broadcast back to the parent channel.

Why interviewers ask this

Dual read models — clients need both the flat channel feed and a paginated thread pane without duplicating storage incorrectly.
Notification geometry — replies should ping subscribers and @mentions, not every channel member unless explicitly broadcast.
Hot spots — viral threads create skewed write/read load on a single thread_root_id.

Scale anchors

Signal	Assumption
DAU	180M
Messages/day	6B (~69k msg/s average)
Thread replies/day	900M (~10k replies/s average, 40× burst on incidents)
Thread open API p99	< 200ms for 50 replies
Reply write p99	< 250ms including fanout enqueue

Architecture headline

Message Service commits parent + reply rows → outbox → Kafka partitioned by channel_id:thread_root_id → Timeline Projector updates channel + thread materialized views → Realtime Gateway pushes thread-scoped events → Notification Orchestrator fans out to subscribers only.

javaOne Dark Pro

1 public record ThreadReply(String threadRootId, String parentId, long threadSeq, String clientMessageId) {}

pythonOne Dark Pro

1 def thread_partition_key(channel_id: str, thread_root_id: str) -> str:
2     return f"{channel_id}:{thread_root_id}"

typescriptOne Dark Pro

1 export interface PostThreadReplyRequest {
2   parentMessageId: string;
3   body: string;
4   clientMessageId: string;
5 }

Why interviewers care

Message Threads interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

The failure that defines the design

The outage to narrate is the stale or wrong thread summary. The parent message shows '3 replies' but the thread has 50, or it shows replies that were deleted — because the denormalized summary on the parent (reply count, participants, last-reply time) drifted from the actual replies. Threads live or die on that summary being correct, since it is what users see in the channel before opening the thread. The fix is structural: append replies to the thread, and update the parent's summary as a reliable derived projection (atomically or via a recoverable async update), never as a best-effort counter that can drift. The summary is the product surface; the replies are the data behind it.

Key Highlights

•Problem Statement & Context: thread-specific design anchor
•Parent/child linkage with monotonic thread sequence
•Notification fanout scoped to thread subscribers

1	def thread_partition_key(channel_id: str, thread_root_id: str) -> str:
2	return f"{channel_id}:{thread_root_id}"

1	export interface PostThreadReplyRequest {
2	parentMessageId: string;
3	body: string;
4	clientMessageId: string;
5	}