Requirements
Questions that change the diagram
Before you start
- Open lesson
Requirements
Estimates and APIs start from an agreed list of what the system must do.
Why it matters
Two people chatting while online is easy to describe; tomorrow and group chat expose the missing promises. “Still be there tomorrow” needs a retention rule, an offline Bob needs a delivery rule, and a 500-person group changes the work behind one send. The scoped design must promise offline delivery and one year of history while stating whether 500-member groups are in scope.
Example
Scope a chat app
Design messaging for two people. Messages should arrive while both are online and still be there tomorrow.
Mental model
The idea
Keep one example in view
Scope a chat app
Design messaging for two people. Messages should arrive while both are online and still be there tomorrow.
Keep this exact scenario and its constraint in view while you build the model.
For Alice and Bob, settle offline delivery and one-year retention first; then ask whether a conversation can have 500 members, because that answer changes one send from one recipient to group fanout.
Start with Alice and Bob online, then change one condition at a time. If Bob disconnects, the product must say whether Alice’s send is accepted and when Bob receives it. Keeping history for one year turns “there tomorrow” into a storage quantity.
Now raise the group limit to 500. One send may have hundreds of recipients, so group size changes the diagram while themes and emoji do not. Ask the questions with different architectural consequences first, and record each answer as a numbered rule.
Pro
The rest of this is on Pro
The idea above is free. The walkthrough, the cost, and the practice are on Pro.