Requirements for the Social Network

Let's define exactly what our Social Network system needs to do. We organize requirements into four subsystems that will map directly to our class design.

User Management:

1. R1: User Registration — The system shall allow a person to create an account with a name, email, and optional bio and profile picture. Each user receives a unique ID.
2. R2: Account Status — A user's account can be ACTIVE, SUSPENDED, or DEACTIVATED. Only ACTIVE users can perform actions (post, comment, like, send friend requests).

Friendship Management:

3. R3: Send Friend Request — An ACTIVE user can send a friend request to another ACTIVE user. The request starts in PENDING status. A user cannot send a request to someone who is already a friend or who has a pending request from them.
4. R4: Accept / Reject Friend Request — The recipient of a PENDING friend request can accept or reject it. Accepting creates a bidirectional friendship — both users appear in each other's friend lists.
5. R5: Unfriend — Either user in a friendship can remove the other from their friend list. The removal is bidirectional.

Content Management:

6. R6: Create Post — An ACTIVE user can create a text post with a privacy setting: PUBLIC, FRIENDS_ONLY, or ONLY_ME. The post records the author, content, timestamp, and privacy level.
7. R7: Comment on Post — An ACTIVE user can add a comment to any post visible to them. Comments can also be added to existing comments (replies), forming a tree structure.
8. R8: Like / Unlike — An ACTIVE user can like a post or comment. Liking is idempotent — liking the same item twice has no additional effect. A user can also unlike (remove their like).
9. R9: Privacy Enforcement — PUBLIC posts are visible to everyone. FRIENDS_ONLY posts are visible only to the author's friends (and the author). ONLY_ME posts are visible only to the author.

Feed & Notifications:

10. R10: News Feed Generation — The system shall generate a personalized news feed for a user consisting of posts from their friends, filtered by privacy rules. The feed generation algorithm shall be pluggable — supporting at minimum chronological ordering and ranked ordering.
11. R11: Notifications — The system shall notify users when: (a) they receive a friend request, (b) their friend request is accepted, (c) someone likes their post or comment, (d) someone comments on their post. Notification delivery shall be decoupled from the action that triggers it.
12. R12: Feed Pagination — The news feed shall support returning a limited number of posts at a time (page size), enabling the caller to request subsequent pages.

Beyond functionality, the design must satisfy:

1. Extensibility (Open/Closed) — Adding a new feed generation algorithm (e.g., trending-based) should require only a new Strategy class — no modifications to the feed service. Adding a new notification channel (push, email) should mean adding a new Observer.
2. Testability — Each service (UserService, FriendService, PostService, NewsFeedService) should be testable in isolation by injecting mock collaborators. The Strategy and Observer patterns enable this.
3. Separation of Concerns — User management, friendship management, content management, and feed generation are distinct subsystems. No class should span multiple concerns.
4. Privacy Correctness — Privacy enforcement must be consistent: a FRIENDS_ONLY post must never appear in a non-friend's feed, regardless of which feed algorithm is active.

In Scope:

• User registration and account lifecycle (active, suspended, deactivated)
• Friend request workflow (send, accept, reject) and unfriend
• Post creation with privacy settings (PUBLIC, FRIENDS_ONLY, ONLY_ME)
• Nested comments (comment on post, reply to comment)
• Likes on posts and comments
• News feed generation with pluggable algorithms
• Notification dispatch on social events

Out of Scope:

• Real-time messaging / chat — that's a separate system (like DP13 Pub-Sub)
• Groups and Pages — these add significant complexity; we focus on the personal social graph
• Media uploads — images, videos, and file storage are infrastructure concerns
• Ads and sponsored content — business logic outside the core social model
• Search — finding users by name or content by keyword is a discovery concern, not a social graph concern
• Database persistence, REST APIs, distributed systems — this is object-level LLD, not system design

Every requirement maps to at least one class in our upcoming design:

Requirement	Maps To
R1 (User Registration)	User class, UserService
R2 (Account Status)	AccountStatus enum on User
R3 (Send Friend Request)	FriendRequest class, FriendService
R4 (Accept/Reject)	FriendRequestStatus enum, FriendService
R5 (Unfriend)	FriendService.unfriend()
R6 (Create Post)	Post class, PostPrivacy enum, PostService
R7 (Comment / Reply)	Comment class, Commentable abstract base
R8 (Like / Unlike)	likes: Set<User> on Commentable
R9 (Privacy Enforcement)	PostPrivacy enum, privacy filter in feed generation
R10 (News Feed)	NewsFeedService, FeedGenerationStrategy interface
R11 (Notifications)	PostObserver interface, NotificationService
R12 (Pagination)	Page size parameter on NewsFeedService.generateFeed()

In a real interview, spend 3–5 minutes clarifying scope before touching the whiteboard. Ask questions like:

• "Should I model Groups and Pages, or focus on the personal social graph?" — Scoping down is expected. Interviewers want to see you prioritize.
• "Is the news feed purely chronological, or should I design for ranked/algorithmic feeds?" — This tells the interviewer you know the domain.
• "Should I handle concurrent friend requests — can two users send each other a request simultaneously?" — Shows you think about edge cases early.
• "Is privacy enforcement in scope — PUBLIC vs. friends-only posts?" — Demonstrates awareness that privacy is a first-class concern, not an afterthought.

The answers to these questions shape your entire class diagram. A candidate who designs without asking them risks building the wrong system.