Design Facebook Privacy
Design a privacy control system for social media posts that manages visibility and access control based on different audience settings: public, private (only-me), friends, and friends of friends.
Asked at:
Meta
A privacy control system for social media posts is the layer that decides who can see content based on audiences like public, only-me, friends, and friends-of-friends. Think Facebook’s post privacy selector: users pick an audience, and the platform consistently enforces it across feeds, profiles, search, notifications, and reshares. Interviewers ask this to assess how you design access control that is graph-aware (friend and FOAF relationships), fast at read time, and consistent across many entry points. They want to see your approach to caching, precomputation vs. on-demand checks, propagation of privacy changes, and prevention of data leaks—skills critical in a system design interview at Meta or similar large-scale social networks.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to set the audience of a post to public, only me, friends, or friends of friends at creation time.
Users should be able to change a post’s audience later, and the system should quickly apply the change across all surfaces (feed, profile, search, notifications).
Users should be able to view posts they are permitted to see, with visibility determined by their relationship to the author at the time of access.
Users should be able to share or link to posts, with the original post’s privacy enforced on reshares and embeds.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
FOAF checks are expensive because they require reasoning over 2-hop relationships on a massive social graph. In a system design interview at Meta, you’re expected to keep read latency low while avoiding memory blow-ups for high-degree nodes. - Consider a layered approach: cache direct friend sets in Redis, and use compact structures (e.g., Bloom filters or sorted sets with degree caps) for approximate FOAF checks, with a precise fallback when needed. - You could precompute and shard friend adjacency lists by user, then use consistent hashing to keep hot users’ data spread across nodes and avoid hotspots. - Think about worst cases (celebrities): impose degree limits, degrade gracefully (e.g., treat FOAF as friends-only or prompt recheck), and add rate limits to protect your graph store.
Privacy is only as strong as your weakest surface. When a user changes an audience or unfriends someone, you must invalidate caches and update feeds, search indexes, and notifications promptly to prevent stale visibility. - Publish change events (privacy updates, add/remove friend edges) on a durable log like Kafka and have consumers update feed stores, search filters, and notification backends idempotently. - Use versioned ACL metadata on posts so you can do atomic cache invalidation and prevent old cache entries from reappearing during races. - For large backfills (e.g., switching hundreds of posts from public to friends), run background workflows that reindex in batches and remove stale entries, while gating reads with the latest ACL version.
Consistency across surfaces is a classic pitfall. Interviewers look for a centralized authorization decision point or a portable policy representation to avoid one-off logic that leaks content. - Centralize authorization with a shared service or library that takes (viewer, author, post, time) and returns allow/deny; make it the only path for access decisions. - Embed visibility tokens or ACL summaries with content in downstream indexes (e.g., search) so you can filter efficiently at query time without duplicating rules. - Use an API gateway to enforce coarse-grained checks and pass signed viewer context to microservices, preventing clients from bypassing checks.
Real systems face policy precedence and tricky edges. Your design should specify how blocks override audiences, how deactivation affects visibility, and how reshares inherit or constrain the original ACL. - Define clear precedence: blocks and safety policies should override FOAF and friends; ensure your auth layer evaluates these first. - For reshares, you could enforce that the effective visibility is the intersection of the resharing audience and the original post’s ACL, never expanding beyond the original. - Maintain an audit trail and metrics for denials/overrides to detect leaks quickly and support abuse investigations.
Relevant Patterns
Relevant patterns that you should know for this question
Privacy checks happen on every read across feeds, profiles, and search. To keep latency low, you need strategies like caching ACL summaries, precomputing friend sets, and pushing filters into read paths and indexes.
Friendship and privacy changes must reflect quickly to prevent leaks. Event-driven updates and cache invalidations enable near real-time propagation across feeds, search, and notifications.
Changing a post’s audience triggers multiple downstream actions: evict caches, update feed stores, reindex search, retract notifications. Modeling this as a workflow with idempotent steps avoids partial updates and races.
Relevant Technologies
Relevant technologies that could be used to solve this question
Similar Problems to Practice
Related problems to practice for this question
Both require filtering a large volume of posts per viewer with low latency. The feed uses the same friend/FOAF checks, caching strategies, and event-driven updates when relationships or ACLs change.
Search must enforce per-document visibility, often by embedding or referencing ACLs and filtering at query time. The same consistency and propagation challenges apply to indexing and result filtering.
Though simpler (public vs. private/followers), Instagram faces similar audience enforcement across feed, profiles, search, and reshares, and uses caching plus event-driven updates for relationship changes.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Performing on-demand graph traversals for every read without caching or precomputation
This leads to high tail latency and overloads graph storage at scale, especially for FOAF checks and high-degree users. It will fail under real-world feed QPS.
Enforcing privacy in one surface (e.g., feed) but forgetting others (search, notifications, reshares, external clients)
Inconsistent enforcement creates data leaks. Attackers or simple UX flows can expose content via less-protected surfaces, breaking user trust and compliance.
Not handling retroactive changes and invalidation (friend removals, audience edits) across caches and indexes
Without versioned ACLs, event-driven invalidation, and idempotent reindexing, stale data will linger and previously authorized viewers may retain access after policy changes.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late August, 2025
Meta
Mid-level
Mid August, 2025
Meta
Senior
Early August, 2025
Meta
Senior
Your account is free and you can post anonymously if you choose.