Design Presentation Collaboration - System Design | WinJob

Problem Statement & Context

Design a Google Slides or Keynote-style collaboration platform where multiple editors manipulate a deck made of slides, scenes, shapes, text boxes, charts, images, comments, and presenter state. The core challenge is that slide decks are spatial documents: concurrent edits can collide on geometry, z-order, animations, and presenter timeline, not just on text ranges.

Why decks are not Google Docs

A document can often model collaboration as ordered text operations. A deck needs stable slide_id and element_id identities so moving one rectangle, editing a chart title, and reordering a slide do not rewrite unrelated elements. Whole-slide last-write-wins is the classic wrong answer because it silently drops a collaborator's shape move or speaker-note edit.

Two real-time channels

Use one durable edit channel for slide ops and one lighter presenter channel for active_slide_id, build step, pointer, and audience mirror state. Editor commits must wait for deck_rev; presenter cues can be lossy and can degrade under load.

Scale anchors

Assume 180M weekly editors, 40M decks touched per day, about 28k peak slide element ops/sec globally, and hot all-hands decks with 5k viewers. Deck open should hydrate snapshot plus thumbnail manifest in roughly p50 180ms and p99 420ms.

Whiteboard sketch

1 [Browser Editor] --WSS--> [Deck Gateway] --> [Deck Coordinator] --> [Deck Op Log]
2                                       |              |
3                                       |              v
4                                       |         [Snapshot Store]
5                                       v
6                               [Presenter Hub] --> [Audience Mirror]

Aha moment

The invariant is one monotonic deck_rev sequence per deck_id. You can shard decks across coordinators, but not split the revision stream for one deck by user or slide. That is what makes undo, replay, comments, exports, and audit explainable.

Failure cases to name

Coordinator restart: clients reconnect with last_seen_deck_rev and catch up from op log.
Hot live deck: batch micro-ops, isolate spectator traffic, and dedicate coordinator capacity.
Asset render lag: show stale thumbnails while preserving slide commit correctness.
Offline editor: queue element-scoped ops with client_seq and reconcile against deck_rev on reconnect.

javaOne Dark Pro

1 public record SlideElementOp(String deckId, String slideId, String elementId, String opType, long baseDeckRev) {}

pythonOne Dark Pro

1 from dataclasses import dataclass
2  
3 @dataclass(frozen=True)
4 class SlideElementOp:
5     deck_id: str
6     slide_id: str
7     element_id: str
8     op_type: str
9     base_deck_rev: int

typescriptOne Dark Pro

1 interface SlideElementOp {
2   deckId: string;
3   slideId: string;
4   elementId: string;
5   opType: "insert" | "update" | "delete" | "transform" | "z_order";
6   baseDeckRev: number;
7 }

Why interviewers care

Presentation Collaboration interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement & Context that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Model slides as element-scoped scene graphs, not whole-slide JSON blobs
•Preserve one monotonic deck_rev stream per deck_id
•Separate durable edit ops from lossy presenter_state fanout
•Degrade thumbnails, cursors, and laser pointers before delaying slide commits

1	[Browser Editor] --WSS--> [Deck Gateway] --> [Deck Coordinator] --> [Deck Op Log]
2	\| \|
3	\| v
4	\| [Snapshot Store]
5	v
6	[Presenter Hub] --> [Audience Mirror]

1	from dataclasses import dataclass
2
3	@dataclass(frozen=True)
4	class SlideElementOp:
5	deck_id: str
6	slide_id: str
7	element_id: str
8	op_type: str
9	base_deck_rev: int

1	interface SlideElementOp {
2	deckId: string;
3	slideId: string;
4	elementId: string;
5	opType: "insert" \| "update" \| "delete" \| "transform" \| "z_order";
6	baseDeckRev: number;
7	}