# Design a collaborative whiteboard like Miro: system design interview question

> A shared canvas must resolve concurrent edits, restore offline work, and keep every client consistent.

Source: https://sysround.com/questions/design-collaborative-whiteboard-like-miro
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a shared whiteboard where people draw, move objects, and add notes together. Users must see changes quickly and continue after a connection loss."

## What to clarify first

- Scale
- Edit traffic
- Read and write mix
- Board size and history
- Latency
- Concurrent edits
- Disconnections
- Durability and availability
- Supported content
- Deployment

## Scope of a strong answer

Core requirements:

- Create and open a shared board
- Draw strokes, move objects, and edit plain-text notes
- Show edits to other users with low latency
- Restore the board and preserve local edits after a disconnect

Usually out of scope:

- Edit note text character by character
- Upload images or video
- Manage accounts and permissions
- Replay the full board history
- Serve users from multiple regions

## What interviewers probe

### Concurrent changes

Users can change the same object before they see each other's edits. Every client must resolve those changes consistently.

### Disconnections and return

A returning client has old board state and local edits. It may also retry edits that the server already accepted.

### Saved edits and server failures

A fast reply can hide an edit that exists only in memory. Failover can also let two servers accept incompatible histories.

### Large busy boards

A single busy board can produce far more deliveries than edits. Slow clients and reconnect bursts can exhaust shared resources.

## Common mistakes

- The design treats a WebSocket as a guarantee of order across users.
- The client replaces the whole board after each edit.
- The server acknowledges edits before durable storage.
- The design names a CRDT but does not define concurrent move and deletion rules.
- The client discards pending local edits when it loads a snapshot.
- The design ignores the delivery cost of one busy board.

## The bar by level

- **Senior:** Define rules for moves, note text, and deletion. Explain durable acknowledgment, retries, snapshot boundaries, and replay without gaps. Prevent slow clients from delaying a board.
- **Staff+:** Prove that writer failover cannot accept conflicting histories. Bound retained history and retry state without losing supported offline work. Quantify busy-board costs and justify the conflict model.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=collaborative-whiteboard


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.