Start by narrowing the problem
A system design prompt is deliberately vague. Before any architecture, you spend the first minutes turning a fuzzy ask into a concrete, bounded problem. Jumping straight to boxes signals that you skip alignment, the most common cause of building the wrong thing.
Functional requirements
These are the features the system must support.
- Core actions like post, follow, search, or pay.
- Out of scope items you explicitly set aside to focus.
- Priorities so you build the critical path first.
Non functional requirements
These shape the architecture more than features do.
- Scale in users, requests, and data size.
- Latency targets and availability goals.
- Consistency needs and durability of data.
Confirm and write it down
Restate what you heard and write the agreed scope where both of you can see it. This becomes the contract you design against, and it lets you defend later tradeoffs.
Key idea
Spend the opening minutes turning a vague prompt into bounded functional and non functional requirements, because a clear scope is what every later decision rests on.