Design Intercom

Intercom Problem Framing and Clarifications

Intercom is a customer-support messaging platform: end users (website visitors, app users, customers) start conversations through an embeddable Messenger widget, and a team of agents answers them from a shared Inbox. The unit that defines the architecture is the conversation, a durable, ordered thread between one end user and the support team that may be touched by bots and several agents over its life, and must stay consistent under retries and concurrent access. Frame it as a conversation system with an agent-facing inbox, not a chat app: the hard parts are conversation integrity, routing conversations to the right agent, and keeping every agent's inbox live.

The spine is therefore: a Messenger widget (end-user side, realtime over WebSocket), an event-sourced conversation timeline where every message, note, and state change is an immutable appended event, an inbox projection that materializes the agent view from those events, an assignment engine that routes each conversation to an agent or team exactly once, bots that handle conversations first and hand off to a human in the same thread, and durable delivery that is at-least-once with idempotent dedup and per-conversation ordering. State the framing up front: the conversation is the source of truth, the inbox is a projection of it, and the design rests on conversation integrity, assignment, and live inbox fan-out.