Section 8: From Firework to Flag - Deep Dive: Extending to Raise Hand
Executive Summary: The interviewer asks for raise hand, and this is where the module is won or lost. We show why "a sixth reaction type" breaks in four ways, separate what carries over from what is new, and build the hand path as a single writer: check permission, dedup by opId, apply, write durably under a ver and epoch condition, ack, and only then broadcast a versioned delta. Then we run three Q&A races through it and watch each converge.
The interviewer nods at the coalescing pipeline from Section 7 and says, almost casually: "Great. Now add raise hand."
The casualness is the trap. The fast answer is wrong: "Add a sixth type to reaction.send. A hand is just an emoji that stays on screen." Say that, and walk it through the pipe you just built:
- Hands get lost. Reactions are at-most-once with a 1 s TTL and shed first under load. A dropped clap is fine. A dropped hand means Maya waits through the whole Q&A for a turn that was never coming.
- There is no order. Coalescing merges clicks into counts. "Hand ×100" cannot tell Maya she is 4th.
- Late joiners see nothing. Reactions are deliberately invisible to anyone who joins afterwards. A queue has to be visible on join.
- Reconnects forget. Maya's 8-second Wi-Fi drop loses every frame sent during the gap. For reactions that's correct. For her hand it's a bug.
You: "Those four failures are the requirement, read backwards: durability, total order, late-joiner visibility, convergence after gaps. Bolting them onto the reaction path would slow reactions down. I'll keep the plumbing and give hands their own semantics."
What Carries Over, What Is New
| Carries over unchanged | New for hands |
|---|---|
| The existing signaling WebSocket and edge gateways | Durable write-through to the hand state document |
| One meeting owner per meeting, routed through the placement directory | Server-assigned order from nextOrder |
| Owner → gateway → connection fan-out tree | ver on every change; snapshot on join plus deltas |
Server-stamped participantId from the session |
opId dedup, persisted in recentOps |
| Two-lane send queues | Hands ride the state lane: ordered and never silently dropped |
| Role-based permission checks for lowering others |
Key Insight: Owning the meeting in one place was a convenience for reactions, because it gave coalescing a single counter. For hands it's essential: the owner is the single writer that gives every change one place in one sequence. Rejecting stateless pub/sub in Section 6 is what makes this extension cheap.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson