Chat vs Live Comments Interviews: What Changes at Senior Level

Chat and live comments look like one real-time problem, but they make opposite promises: chat promises every message to every member, in order, even after time offline, while live comments promise a bounded, correctly moderated live view of one hot room, with history served from a separate read path. As of 2026-10-18, the TrueInterview bank holds 29 candidate-reported chat and live-comment design questions from 17 big-tech companies. Our take: the dangerous follow-ups are the ones where you carry one problem's contract into the other, so state the contract before you draw a single box.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

How do chat and live comments differ, side by side?

The Engineering Enablement author says a chat system must guarantee delivery to an offline recipient once they reconnect, with pending messages delivered in order. For live comments, systemdesign.one's public design lets receivers ignore comments while disconnected, and Hello Interview's breakdown says viewers can see comments made before they joined. Every other row in the table below follows from that single difference, so learn the contract row first.

Our take: pick chat as your default practice problem and treat live comments as its mirror image. A candidate who can explain why each row flips will handle either prompt; a candidate who memorised one diagram will not.

On protocol, both problems want persistent connections over polling. Hello Interview's live comments breakdown says polling "doesn't scale" as comments and viewers grow. MDN describes server-sent events as a one-way connection that restarts automatically and carries a last event ID for resuming. That makes SSE a natural fit for viewing live comments, with posting sent as a separate HTTP request, as the System Design Handbook guide notes. For chat, the Engineering Enablement author says interviewers care more about whether you see the need for persistent connections than about WebSocket protocol details. Spend your minutes on the contract, not on the handshake.

Which companies report chat vs live-comment prompts, and in which round?

Messaging-style prompts, with chat and comments counted together, dominate the reports. Of the 29 questions, 18 fall in the chat, messaging and comments family and 7 are LLM, RAG and AI infrastructure designs. OpenAI leads with 6, then Databricks with 5 and Meta with 4. The bank's example live-comment report is a Meta onsite, last reported 2026-04; our family counts do not separate live comments from chat, so read it as one dated example rather than a company split.

Slack-like group chat draws more than twice the write-up links of 1-to-1 chat. If you have time for one full mock, make it group chat, because a group design already contains the one-to-one case.

By round, 25 of the 29 questions were reported for the onsite and 7 for the phone screen, and a question can appear in both. Do not assume the phone screen is safe. Anthropic's 1-to-1 chat and Amazon's Design a Reliable AI Chatbot Architecture were both reported there, the second in 2026-08. Recency is high as well: 27 of the 29 were last reported within the 12 months before 2026-10-18, so these prompts are current, not leftovers from older loops.

What do chat questions push on?

Chat questions push on durable, ordered, offline delivery, not on the socket. The Engineering Enablement author says interviewers explore offline delivery because it raises reliability questions, asking "What happens if a server crashes while processing messages?". Prepare that answer before you prepare your diagram.

Build your chat answer around four decisions:

1. Durable storage separate from delivery. The Engineering Enablement author says messages belong in durable storage so history survives a disconnect. The same Engineering Enablement post says fast-changing presence belongs apart from message storage, in fast in-memory storage.
2. Time-sortable IDs and a partition key. Discord partitions messages by channel plus a static time-window bucket, with IDs that sort chronologically. Use the pattern as an illustration, not as what an interviewer expects.
3. A pending-delivery path for offline users. On reconnect, the recipient pulls what was pending in order. Name where that pending state lives and what happens when the server holding it crashes.
4. Clarifying questions first. The Engineering Enablement author lists 1-to-1 vs group, media, delivery confirmations, typing indicators, read receipts and search. Receipts and typing indicators each add a write path, so confirm them before you size anything.

A follow-up worth raising yourself is the hot channel. Discord notes that a small friend server sends orders of magnitude fewer messages than a server with hundreds of thousands of people. Concurrent reads can hotspot one partition, and Discord says a hot partition "frequently affected latency across our entire database cluster". Discord's blog says its mitigation was request coalescing: when many users request the same row at once, the database is queried once. Our take: at senior level, raising the hot-channel problem yourself, before the interviewer does, is worth more than any extra box in the diagram.

What do live-comment questions push on?

Live-comment questions push on one hot room: fan-out bandwidth, sampling and moderation ordering. PracHub's guide argues the design becomes useful when you can explain three failures together: comment volume beyond reading speed, slow connections falling behind, and a moderator removal racing a late publication event. Rehearse all three as one story.

PracHub's guide makes the separation explicit: keep durable comment state apart from the live presentation stream. The guide's illustrative arithmetic shows why sending everything to everyone fails, at 10 million deliveries per second and about 3 GB per second of payload. Treat that as worked arithmetic, not a measured system. Discord's own numbers show the same pressure in a real product: anything published in a guild fans out to every connected session, and at peak, publishing from a large guild took 900ms to 2.1s.

Three rules carry most of the follow-ups:

• Sampling never drops removals. PracHub's guide says "Sampling must not discard removals for comments a client might hold."
• A version per comment. PracHub's guide says a comment version decides which state supersedes another, so a deletion that arrives before its delayed publication keeps the comment hidden. Trace this on paper once; it is the clearest way to show you understand ordering.
• Commit and publish together. PracHub warns that a commit followed by a failed publish can leave a visible comment absent from every live viewer. Name an outbox or a replayable log as your fix.

PracHub also notes that sharding unrelated rooms raises total throughput but leaves the hottest room's ordering bottleneck in place. Our take: this is the sentence that separates senior answers. Sharding is the default reflex, and live comments is built to punish it.

Which misreadings fail the follow-ups?

Three misreadings are worth guarding against, and each comes from carrying one contract into the other problem. The fix in every case is to restate the contract and let it decide the design; it costs one sentence and keeps the rest of the round on the follow-ups that matter.

• Treating live comments as group chat with more people. PracHub's guide keeps offline inbox delivery and presence out of scope for live comments. A chat design over-invests in exactly the parts this prompt does not need, then has nothing left for hot-room fan-out.
• Assuming sharding by room finishes the job. One very large server could still hotspot a partition at Discord, and the hottest room keeps its ordering bottleneck.
• Treating moderation as an extra. The System Design Handbook guide says moderation must operate at the same speed as the comment stream. PracHub's guide treats a removal racing a late publication as a correctness failure. If you skip moderation, you skip the hardest follow-up.

Reconnects deserve one more line. Discord found that timed-out requests retried after backoff piled up into an unrecoverable state. Whether the prompt is chat or live comments, say how a mass reconnect is spread out and how a client resumes from its last event ID.

Is an AI chatbot prompt the same as a messaging prompt?

No. AI chatbot prompts are a third variant with their own focus. Seven of the 29 questions are LLM, RAG and AI infrastructure designs, including Design AI Chatbot App (OpenAI, Apple, Databricks, Uber) and Amazon's reliable AI chatbot architecture. Prepare one separately from your messaging mock.

The per-company mix shows where this matters. OpenAI's set splits 4 chat and 2 LLM designs, Databricks 4 and 1, and Uber 2 and 1. Meta, Anthropic and Lyft are all chat, messaging and comments. The bank files Design ChatGPT under the chat, messaging and comments family, and it is filed under Amazon, Anthropic and OpenAI.

Our take: the deciding questions in an AI chatbot design are the eval set, the fallback when the model fails or is slow, and how streamed tokens reach the client. The message store is the easy part. If OpenAI, Amazon or Databricks is in your loop, budget one mock for this variant; for Anthropic, our data shows only chat-family prompts, so Design ChatGPT is the closest overlap.

What changes at senior and staff level?

Write-ups linking these prompts come mostly from senior candidates, which may partly reflect who writes reports. Write-ups link them 47 times from candidates who reported a senior, staff-plus or manager level, against 11 from junior, new-grad or intern candidates. Slack-like chat alone is 15 to 3, and 1-to-1 chat is 5 to 3. Expect the interviewer to assume the baseline architecture.

Staff-plus or manager write-ups link 1-to-1 chat, Slack-like chat and LinkedIn's AI-Powered Personalized Recruiter Message Generation. These levels are self-reported by candidates, so read them as a skew, not a rule.

What this means for your answer, as our view:

• Mid level: a working design with storage, a push channel and history load.
• Senior: the contract stated up front, a fan-out or hot-partition estimate, and the crash and reconnect paths. The Engineering Enablement author says strong candidates "use scale estimates to justify later architectural decisions".
• Staff: trade-offs argued out loud: sampling vs completeness, coalescing vs freshness, and when you would change the design. Hello Interview's breakdown says you can jump to the more complex solution if you justify it and explain trade-offs.

Down-leveling note (our view): in these loops the level signal sits mostly in design depth. A clean diagram with no failure handling reads as mid level, even from a strong engineer. If you run out of time, cut breadth and keep one deep failure trace.

How we counted

We counted design questions in the TrueInterview bank whose titles place them in the chat, messaging, live-comment or chatbot space, as of 2026-10-18. Write-up links count candidate interview write-ups that link a question, and levels are the candidate's own reported level. These are candidate-reported questions reconstructed for practice, not any company's official list, and a count measures what candidates reported, not how often a company asks.

FAQ

What is the core difference between a chat and a live-comment system design?

The contract. The Engineering Enablement post says chat must guarantee delivery to an offline recipient and deliver pending messages in order after reconnect. Live comments must show a bounded, moderated live view of a hot broadcast, with earlier comments loaded as history on join rather than replayed as missed deliveries. Storage, ordering and fan-out choices all follow from which promise you are making, so say it in the first minute.

Should I use WebSockets, SSE or polling?

Use a persistent connection for both. The System Design Handbook guide says SSE is one-way, so posting a comment needs a separate HTTP request. For live comments, accept that split and keep posting as a plain request. Chat needs two-way traffic, so WebSockets are the usual choice. Polling works for a first sketch and fails at scale, which is worth one sentence before you move on.

How do you handle one broadcast with millions of concurrent viewers?

Separate durable state from the live stream, push through a gateway layer that holds connections, and sample ordinary comments when volume exceeds reading speed. PracHub's guide says that if the interviewer requires every comment at every client, sampling goes and you accept larger bandwidth and recovery costs. Ask which version the interviewer wants before you size anything.

How do you stop a deleted comment from reappearing?

Give every comment a version and apply only newer states. When a removal arrives before the delayed publication, the client already holds the higher version and keeps the comment hidden. Make removals exempt from sampling, so a client never misses one for a comment it is showing.

Is Slack-like group chat asked more often than 1-to-1 chat?

In our data, Slack-like chat is linked from more candidate write-ups than the one-to-one prompt, which reflects what candidates reported rather than how often a company asks. For practice, a group design already contains the one-to-one case, so it is the better first mock.

Your practice plan

A three-week plan for someone working full time:

1. First evening: write the one-sentence delivery contract for chat and for live comments, and open every mock with it.
2. First week: run a full mock of Design Slack-like Chat System, the prompt ByteDance candidates reported for the onsite. Answer three follow-ups: an offline user reconnecting, a chat server crashing mid-delivery, and one channel becoming a hot partition.
3. First week, for Anthropic or Lyft: add Design a 1-to-1 Chat System, reported in an Anthropic phone screen, and Design Facebook Messenger.
4. Second week: run Design real-time live comments, the Meta onsite example. Do a back-of-envelope fan-out estimate, then trace on paper a removal that arrives before its delayed publication.
5. Second week, if Databricks is on your list: practise Design Chat APIs, Storage, and Message Flows with the API surface written out first.
6. Third week: if OpenAI, Amazon or Databricks is in your loop, run Design AI Chatbot App or Design a Reliable AI Chatbot Architecture, focusing on evaluation and fallback.
7. Third week, last session: redo your weakest mock with a short, fixed time box on the baseline design and the rest spent on failure handling.

Sources

• TrueInterview question bank — chat and live-comment design at big-tech companies — counted 2026-10-18
• How I would design a real-time chat application in a System Design interview — checked 2026-10-18
• Live Comment System Design - System Design — checked 2026-10-18
• Design Facebook's Live Comments System | Hello Interview System Design in a Hurry — checked 2026-10-18
• Live Commenting System Design: Hot Broadcasts, Fan-Out, and Moderation Ordering | PracHub Knowledge Hub — checked 2026-10-18
• How Discord Stores Trillions of Messages — checked 2026-10-18
• Using server-sent events - Web APIs | MDN — checked 2026-10-18
• Design Live Comment System: A Complete Guide — checked 2026-10-18
• How Discord Scaled Elixir to 5,000,000 Concurrent Users — checked 2026-10-18

Last reviewed: 2026-10-18.