In general, most of the discussions around System Design are backend heavy, involving Databases, Microservices , Load Balancers and what not. But in this write up I'll try to give a point of view from the other end of the spectrum . As a frontend engineer, you are the one actually closest to the user and the decisions you make or fail to make are instrumental in deciding whether the system is even worth building .

This article will be like a design session that is documented *.* Like we do in a System Design discussion, we'll take one non-trivial product and reason through it from first principles. Our use-case for today : A Realtime Collaborative Whiteboard Tool , think of it as Figma's multiplayer canvas or Miro , I feel this would be complex enough to cover quite a bit of what we are trying to address here.

The Art Of Scoping

Quite a few people treat this part as a trivial formality, it's not ! Every ambiguity you leave here will lead to a pathway translating to an architectural decision made by accident later on. Three fundamental categories need to be addressed over here .

Functional Requirements - This answers "what the system does". Lets answer these targeting our use-case.