Kanban board - ordering cards without renumbering them

Why this design

A kanban board is a list that many people reorder at the same time while watching each other do it. That makes two questions that every task tool - Trello, Jira, Linear, Asana, GitHub Projects - has had to answer: how do you store the order of cards so that moving one does not rewrite the others, and how do twenty open tabs stay in agreement without a refresh. Interviewers like it because it looks like CRUD and is really an ordering problem plus a fan-out problem, and the naive answer to each (an integer position, broadcast everything) fails in a way you can calculate.

What you will learn

• Why an integer position column turns one drag into a renumbering of the whole column, and how a fractional rank string makes a move one row.
• How "key between a and b" works in base 62, why keys grow about one character per six inserts into the same gap, and when to rebalance.
• Why the rank column must use a byte-order ("C") collation, or "a0V" and "a0v" sort differently in production than in tests.
• A per-board sequence number written in the same transaction as the change, so clients can detect and repair a missed event.
• Optimistic moves on the client, rebased when the server's version of events arrives.
• WebSocket fan-out through a pub/sub channel per board, and what one move costs on a board 500 people have open.

How to read this board

1. Press Play. CLIENT on the left, the WRITE in the middle, then the FAN-OUT along the bottom.
2. 1 · Requirements and 2 · Capacity - why moves are cheap and fan-out is not.
3. 3 · Storage - cards, ranks and the event log.
4. 4 · Availability - reconnects, missed events and a gateway node dying with 40,000 sockets.
5. 5 · How it works, 6 · Deployment plan, then the DATA MODEL.

Ask these before drawing anything

• How large does a board get? A team board has 200 cards; an imported backlog has 20,000. Ordering and rendering choices change at the second number.
• How many people have one board open at once? Usually 1 to 20; an all-hands planning board can be 500.
• Must order be the same for everyone at every instant, or is "converges within a second" acceptable? It is always the second.
• Is offline editing in scope? It changes conflict handling from "last writer wins with a fresh view" to genuine merging.
• Are there automations or integrations that move cards in bulk?

Functional

• Create, edit, move cards within and between columns; reorder columns.
• A move is shown immediately to the person making it and to every other viewer within 1 second.
• Two people moving cards at the same time both see the same final order.
• A client that disconnects and reconnects catches up without reloading the board.

Non-functional

• Move latency as felt by the mover: 0 ms (optimistic). Server acknowledgement p99 under 150 ms.
• Fan-out p99 under 500 ms from commit to every connected viewer.
• A move writes O(1) rows regardless of column length.
• No lost moves: every committed change is recoverable by sequence number for 30 days.