</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 2: Two Contracts in One Button - Requirements (Functional & Non-Functional)

Executive Summary: Section 1 found that reactions and raise hand look alike on screen and behave as opposites underneath. This section writes that difference down as two contracts. Reactions promise speed and tolerate loss: near-real-time delivery, crowd counts, at most 1% dropped, 99.9% availability that may degrade. Raise hand promises correctness: a server-ordered queue, zero acknowledged changes lost, late joiners who see everything, 99.99% availability. A third requirement binds both, and no feature list would surface it: reactions must never degrade audio, video or hand state.

The interviewer caps the marker: "So what exactly are you committing to?" A weak answer lists features. A strong answer writes promises a test can check and an on-call engineer can be paged on. This problem adds a second trap: a single requirement list quietly hands both features the same guarantees, and whatever you pick will be wrong for one of them. So say it out loud: "I'm writing two contracts, because this button makes two kinds of promise."

The Functional Contract for Reactions

# Requirement Note
FR-R1 Send one of five reactions: like, heart, applause, laugh, surprised Any participant allowed to react. Phone dial-in can't, as agreed in Section 1
FR-R2 Everyone else in the meeting sees it float across their screen, near-real-time The sender sees their own reaction instantly (local echo)
FR-R3 When the room is busy, show a crowd effect plus counts instead of every single emoji Maya sees a wave and "applause ×248", not 1,800 separate hands clapping
FR-R4 The organizer can switch reactions off for a meeting A meeting option, enforced on the server
FR-R5 Late joiners see nothing from before they joined A firework you missed is gone

FR-R3 and FR-R5 would be bugs in a messaging product. Here they are allowed only because a reaction is worth nothing a second later.

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

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.