Getting Ready: Social Network

Facebook serves over 3 billion monthly active users. Every time someone opens the app, a News Feed is assembled in real time — collecting posts from hundreds of friends, scoring each one for relevance, and returning a personalized, ranked list in under a second. Behind this seemingly simple experience is an object model that powers friendships, posts, comments, reactions, notifications, and privacy controls.

What makes a Social Network an exceptional hard-difficulty LLD problem is the sheer variety of design challenges packed into one system:

• Graph-based relationships — Friendships are bidirectional edges in a social graph. Friend requests go through a state machine (PENDING → ACCEPTED / REJECTED). Modeling this cleanly requires understanding both graph data structures and state management.
• Composite content structure — Posts can have comments. Comments can have replies. Replies can have replies. This recursive tree structure is a textbook application of the Composite Pattern — treating individual comments and nested reply threads uniformly.
• News Feed generation — The feed is not simply "all my friends' posts sorted by time." Real systems use ranking algorithms that weigh affinity (how often you interact with a friend), content type (photo vs. text), engagement signals (likes, comments), and recency. This is a natural Strategy Pattern — swap the feed algorithm without touching the feed service.
• Observer-driven notifications — When someone likes your post, comments on your photo, or sends you a friend request, you get a notification. Decoupling "what happened" from "who to notify" is the Observer Pattern.
• Privacy controls — Posts can be PUBLIC, FRIENDS_ONLY, or ONLY_ME. The system must enforce visibility rules when generating feeds and displaying content.

This problem appears in LLD interviews at Meta, Google, Amazon, LinkedIn, and Twitter because it tests whether you can model a system with multiple interacting subsystems — user management, content management, graph operations, and feed generation — all with clear boundaries between them.

By the end of this design problem, you will be able to:

• Model a social graph — design User and FriendRequest classes that represent bidirectional friendships with a proper request/accept workflow
• Design composite content — build a Post/Comment hierarchy where comments can nest arbitrarily deep using the Composite Pattern
• Implement news feed generation — apply the Strategy Pattern to support multiple feed algorithms (chronological, ranked) without modifying the feed service
• Wire up event-driven notifications — use the Observer Pattern so that likes, comments, and friend requests trigger notifications without coupling services
• Enforce privacy at the object level — filter posts by privacy setting during feed generation
• Create four UML diagrams — Use Case Diagram (actor interactions), Class Diagram (structural blueprint), Sequence Diagram (post creation flow)
• Write complete implementations split across two code tutorials — Users & Friendships, and Posts & Feed — in both Python and Java
• Build a News Feed Generation Algorithm — trace a ranked feed algorithm step-by-step with affinity scoring, content weighting, and time decay
• Apply and justify four design patterns — Observer, Composite, Strategy, and Facade — with trade-off analysis

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition (User owns Posts) and Association (FriendRequest references two Users) — Fundamentals S4
• Inheritance & Abstract Classes — the Commentable base class for Post and Comment — Fundamentals S3
• Observer Pattern — how subjects notify observers of state changes (used for notifications on likes, comments, friend requests) — Fundamentals S12
• Composite Pattern — treating individual objects and compositions of objects uniformly (used for the Post/Comment tree) — Fundamentals S11
• Strategy Pattern — how swappable algorithms avoid if/else chains (used for feed generation) — Fundamentals S12
• UML Class Diagrams — reading class boxes, relationship arrows, and multiplicities — Fundamentals S5
• UML Sequence Diagrams — reading lifelines, messages, and activation bars — Fundamentals S5

If you've completed the medium design problems (DP8–DP18), you already have experience with state machines, multi-actor systems, and Strategy Pattern. This problem builds on those foundations with deeper graph modeling and algorithmic complexity.

We will design: The core domain logic — User accounts, friend request workflow, post/comment/like management, news feed generation with pluggable ranking, notification dispatch, and privacy enforcement.

We will NOT design: Database schemas, REST APIs, distributed systems (sharding, caching, CDN), real-time messaging/chat, image/video upload pipelines, ad targeting, group/page management, or the UI layer. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

What distinguishes this from other problems:

• Unlike the Pub-Sub System (DP13) which is a generic messaging pattern, the Social Network has a domain-specific graph structure (friendships) that drives both content visibility and feed generation.
• Unlike Stack Overflow (DP18) which has a reputation/voting system, the Social Network focuses on feed ranking — algorithmically curating content rather than sorting by votes.
• Unlike the Notification System (DP31) which is channel-focused (email, SMS, push), here we focus on what triggers notifications and how they integrate with the social graph.