Design Trello (Kanban Board)

Problem statement

Design a web-based Kanban board service where users create cards for tasks, organize them into lists on a board, and drag cards between lists and positions. Multiple collaborators edit the same board simultaneously, so every structural change — a card moved, a list renamed, a comment added — must be visible to all viewers within a couple of hundred milliseconds. The product also needs notifications, attachments, permissions, search, and an activity feed that never loses an event.

The instinct is to treat this as a boring CRUD application: a board is a tree of lists and cards stored in a database, edited through REST calls. That framing fails the interview. The real problem is a concurrent ordering system: dozens of users may drag cards on the same board at the same second, clients have unreliable networks and go offline, and every viewer must converge on one consistent visual order without anyone's drag being silently lost or duplicated. Card order is the hardest field in the whole system because it is a relative property — moving one card perturbs the positions of its neighbors — unlike a title, where last-write-wins is obviously acceptable.

Why the problem is distinctive

A note-taking app can retry a save. A board cannot tolerate a duplicated card, a card vanishing from two lists at once, or two users seeing different orders for minutes at a time. The design therefore separates durable truth from live projection. Durable truth is the committed board state: lists, cards, positions, memberships, comments, activity events. Live projection is what connected viewers are looking at right now: presence cursors, in-flight drag ghosts, typing indicators, and optimistic updates that have not round-tripped yet. A strong answer keeps these planes separate, makes the committed state the only authority, and treats every client's local view as a cache that reconciles against a per-board ordered event stream.

The attached brief requires board and list creation, renaming and reordering; card creation with labels, attachments, and checklists; real-time multi-user drag-and-drop sync; and permissions for private and shared boards. It asks for scalability across many boards, low-latency collaborative updates, zero duplication or data loss on refresh, and search indexing over cards and attachments.

Public operating baseline versus design assumptions

Public evidence establishes that the category operates at serious scale. Trello reported more than 25 million registered users and more than one billion cards created by 2019, and engineering posts from the team describe roughly ten million cards created per day at that time; Atlassian acquired Trello in January 2017 for 425 million dollars. Linear publicly describes a sync-engine architecture where the client holds a full working set and exchanges deltas, and Figma's multiplayer engineering post describes an authoritative server model where clients send operations and receive merged state. These are cited company signals, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature product with 5 million daily active users, 80 million monthly actives, 1.2 million concurrently connected users at peak, and a 5x event peak for morning standups and launch days. Unless a number is tied to a citation, it is a stated design assumption, target, or budget — not a claim about any company's private architecture.

The four architectural planes

1. Ordering plane: fractional indexing, conflict resolution for concurrent moves, rebalancing of position keys, and the invariant that a card belongs to exactly one list at exactly one position.
2. Real-time plane: WebSocket gateways, per-board rooms, presence, fanout with coalescing for hot boards, and resumable subscriptions.
3. Mission plane: durable board/list/card/comment workflows, permissions, notifications, activity feed, attachments, and search indexing.
4. Learning and operations plane: telemetry, feature flags, abuse and spam controls, audit evidence, and release gating.

A strong interview answer keeps these planes separate. It allows the real-time plane to degrade — viewers temporarily polling — without weakening the ordering plane, and it lets the operations plane observe everything without being able to rewrite committed state.