Problem
Design the frontend of Trello, a Kanban board: boards with lists (columns) of cards that people drag around, together, in real time. It is one of the most reported Atlassian frontend system design questions, and it also comes up as "design a Jira board" or "design a sprint board".
Functional requirements
- Move cards up and down a list and across lists with drag and drop. Creating and editing boards, lists and cards is basic.
- Open a card to see and edit its details: description, labels, members, due date, checklists, comments.
- See teammates' changes live, without refreshing.
Constraints
- Boards of up to about 5,000 cards, and up to about 100 people working on one board at the same time.
- Every action shows on screen in under 100 ms, whatever the network is doing, and dragging runs at 60 frames per second.
- Teammates see a change within about 1–2 seconds.
- No change is lost on a flaky connection or while offline.
- Works on phones and tablets (touch dragging), and is accessible to WCAG 2.2 AA: keyboard, screen reader and touch.
Discussion areas
- Core entities and key actions: what the board, lists, cards and card details are, and which user actions shape the design.
- Architecture: rendering approach, the layers between UI components and the server, the component tree, and how the card detail view fits in.
- Data model: how boards, lists and cards live in the client store, and what to load with the board versus when a card is opened.
- Ordering: how to store the order of cards so that moving one card doesn't rewrite the whole list.
- API and live updates: REST endpoints for loading and writes, how teammates' changes reach the browser, and catching up after a disconnect.
- Optimistic updates: showing a move instantly and undoing only the change that failed.
- Conflicts: two people changing the same card, late events overwriting fresh data, and small fields versus long text.
- Error handling and offline: which failures to retry and which to give up on, and replaying changes made offline.
- Performance: a 60fps drag, boards with thousands of cards, and bursts of incoming updates.
- Accessibility: moving cards without a mouse, announcing moves, and focus handling in the card view.
Follow-up questions interviewers ask
- Why SSE and not WebSockets?
- Dropping the last card at the top moves every card on screen. Why is only one card written?
- Why a pending queue instead of a snapshot to roll back to?
- What if my own SSE event arrives before the REST response?
- Isn't a card version enough? Why also an event id?
- What if the SSE connection dies silently?
- How do several open tabs work?
- Virtualization or
content-visibility: auto?