Model a Kanban move as a transaction over stable card and lane identities. Render an optimistic projection immediately, persist an idempotent anchor-based operation against a board revision, and rebuild from the accepted snapshot when acknowledgements or remote edits arrive.
A small board looks like a few arrays and a drag handler. That model breaks when two people move the same card, a filtered card disappears, a long lane virtualizes most of its DOM, or a retry applies twice. The hard part is not drawing a card under the pointer. It is preserving one understandable board through latency and disagreement.
Start with accepted state plus pending intent
Keep two layers of state:
- the latest board snapshot accepted by the server;
- ordered local operations that have not settled yet.
The visible board is a projection of both layers. A quick cross-lane move feels immediate because the pending operation is projected locally. When the server accepts it, the new snapshot replaces the old one and that operation leaves the pending queue. When the server corrects or rejects it, recompute from the returned snapshot instead of trying to reverse arbitrary UI mutations.
This gives the design a useful invariant: every visible card comes from one accepted entity plus a deterministic sequence of pending operations.
The public interview prompt
Design a sortable Kanban board component for a collaborative project-management product. Explain:
- normalized board, lane, card, and membership data;
- ordering within lanes and moves across lanes;
- drag, keyboard, and click or tap alternatives;
- optimistic updates, idempotency, revisions, conflicts, rollback, and undo;
- subscriptions, reconnects, offline retry, permissions, and deleted cards;
- horizontal board scrolling, vertical lane scrolling, auto-scroll, and virtualization;
- filters, collapsed lanes, selection, focus recovery, and screen-reader announcements;
- performance budgets, instrumentation, tests, and staged rollout.
Assume a board can contain 200 lanes and 100,000 cards, while a typical viewport shows six lanes and fewer than 100 card rows. Several users may edit the same board. These numbers are design assumptions for the interview, not measured product facts. Rich-text card editing, a free-form canvas, and the generic drag sensor implementation are outside version one.
What the premium solution covers
The full solution defines normalized storage, an anchor-based move API, sparse position keys and bounded rebalancing, optimistic projection, conflict policies, real-time and offline ordering, permissions, accessibility alternatives, focus behavior, large-board rendering, cleanup, observability, tests, and an interview answer rubric.
Original media demonstrates acknowledgement and conflict correction, compares normalized and nested state, explains ordering gaps, and maps a two-axis rendering budget. Two deterministic labs let you exhaust ordering space and replay concurrent operations without a backend.