Practice/Apple/Design Online Block Diagram Maker

Design Online Block Diagram Maker

System DesignMust

Problem Statement

Design a collaborative, browser-based tool for creating block diagrams — think Lucidchart, Miro, or Figma. Users create boxes, connectors, and annotations on an infinite canvas. Multiple people can edit the same diagram simultaneously, seeing each other's cursors and changes in real time.

The key challenges are real-time collaboration (conflict resolution when two people edit the same shape), efficient rendering of an infinite canvas (only loading what is visible), and managing WebSocket connections at scale. This problem blends real-time systems, spatial data modeling, and distributed state synchronization.

Key Requirements

Functional

Diagram editing -- users create, move, resize, connect, and style shapes on an infinite canvas with pan and zoom
Real-time collaboration -- multiple users see each other's cursors, selections, and edits with sub-200ms latency
Sharing and permissions -- diagram owners control access (view, comment, edit) and invite collaborators
Version history -- users can undo/redo and browse previous versions of the diagram

Non-Functional

Scalability -- support thousands of concurrent diagrams with up to 50 simultaneous editors per diagram
Latency -- edits propagate to all collaborators within 200ms
Consistency -- all users must converge to the same diagram state, even after concurrent conflicting edits
Reliability -- no data loss on server crashes; diagrams are durably stored

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Conflict Resolution for Concurrent Edits

When two users simultaneously move the same shape or edit the same label, the system must merge their changes without losing either edit.

Hints to consider:

For shape properties (position, size, color), last-writer-wins per property with vector clocks often works well
For text content within shapes, consider Operational Transformation (OT) or CRDTs for character-level merging
Shapes are independent objects — concurrent edits to different shapes never conflict, so conflict resolution is per-shape
Discuss soft-locking: show a visual indicator when someone is editing a shape to reduce conflicts in practice

2. Infinite Canvas and Viewport-Based Loading

A diagram can be enormous, but each user only sees a small viewport. Loading the entire diagram upfront wastes bandwidth and memory.

Hints to consider:

Tile the canvas into spatial chunks (e.g., 1000x1000 pixel regions) and only load chunks that intersect the viewport
Use spatial indexing (R-tree or quadtree) to quickly find which shapes are visible for a given viewport
Subscribe to real-time updates only for chunks the user can see — no need to receive edits for off-screen shapes
Pre-fetch neighboring chunks as the user pans to reduce perceived loading time

3. WebSocket Architecture for Real-Time Updates

Each active diagram needs a channel where all connected users exchange edits and presence information. Managing thousands of concurrent WebSocket connections requires careful design.

Hints to consider:

Use stateless WebSocket gateway servers that subscribe to diagram-specific channels via Redis Pub/Sub
Include a sequence number with each operation so clients can detect missed messages and request replay
Batch rapid successive edits from the same user (e.g., dragging a shape generates dozens of position updates)
Handle reconnection gracefully: on reconnect, fetch the latest snapshot and replay missed operations

Practice/Apple/Design Online Block Diagram Maker

Design Online Block Diagram Maker

System DesignMust

Problem Statement

Key Requirements

Functional

Diagram editing -- users create, move, resize, connect, and style shapes on an infinite canvas with pan and zoom
Real-time collaboration -- multiple users see each other's cursors, selections, and edits with sub-200ms latency
Sharing and permissions -- diagram owners control access (view, comment, edit) and invite collaborators
Version history -- users can undo/redo and browse previous versions of the diagram

Non-Functional

Scalability -- support thousands of concurrent diagrams with up to 50 simultaneous editors per diagram
Latency -- edits propagate to all collaborators within 200ms
Consistency -- all users must converge to the same diagram state, even after concurrent conflicting edits
Reliability -- no data loss on server crashes; diagrams are durably stored

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Conflict Resolution for Concurrent Edits

When two users simultaneously move the same shape or edit the same label, the system must merge their changes without losing either edit.

Hints to consider:

For shape properties (position, size, color), last-writer-wins per property with vector clocks often works well
For text content within shapes, consider Operational Transformation (OT) or CRDTs for character-level merging
Shapes are independent objects — concurrent edits to different shapes never conflict, so conflict resolution is per-shape
Discuss soft-locking: show a visual indicator when someone is editing a shape to reduce conflicts in practice

2. Infinite Canvas and Viewport-Based Loading

A diagram can be enormous, but each user only sees a small viewport. Loading the entire diagram upfront wastes bandwidth and memory.

Hints to consider:

Tile the canvas into spatial chunks (e.g., 1000x1000 pixel regions) and only load chunks that intersect the viewport
Use spatial indexing (R-tree or quadtree) to quickly find which shapes are visible for a given viewport
Subscribe to real-time updates only for chunks the user can see — no need to receive edits for off-screen shapes
Pre-fetch neighboring chunks as the user pans to reduce perceived loading time

3. WebSocket Architecture for Real-Time Updates

Each active diagram needs a channel where all connected users exchange edits and presence information. Managing thousands of concurrent WebSocket connections requires careful design.

Hints to consider:

Use stateless WebSocket gateway servers that subscribe to diagram-specific channels via Redis Pub/Sub
Include a sequence number with each operation so clients can detect missed messages and request replay
Batch rapid successive edits from the same user (e.g., dragging a shape generates dozens of position updates)
Handle reconnection gracefully: on reconnect, fetch the latest snapshot and replay missed operations