Meta·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

Apr 2026

Summary

Meta system design round focused entirely on post privacy, the kind of problem that sounds scoped until you start pulling on the caching thread and realize how many edge cases are hiding in there. Solid problem, made me think harder than expected.

Questions Asked (1)

Design a privacy system for social media posts that supports multiple visibility levels (public, friends, friends-of-friends, only me, and custom allowlist/denylist/groups), enforces those rules on both feed reads and direct URL access, and handles high read throughput with caching while staying consistent when friendships or privacy settings change.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with the data model, which felt natural, but I spent too long on the schema and not enough time on the enforcement layer.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a data model that separates post content from privacy metadata and relationship graphs. Propose a read path that uses caching and precomputed visibility sets for common cases, with fallback to real-time checks for custom lists, and a write path that invalidates or updates caches on friendship/privacy changes. Discuss trade-offs between consistency, latency, and cost, and how to handle direct URL access with the same enforcement logic.

Pro tip: Emphasize that privacy enforcement must be centralized in a single service to avoid inconsistencies, and that caching should be keyed by viewer-post pair or viewer group to enable efficient invalidation on relationship changes.

1. Clarify requirements and scale

Ask about read/write QPS, latency targets, consistency requirements, and the scale of the social graph. Confirm that privacy must be enforced on both feed and direct URL access, and that custom lists can be large.

2. Design data model and privacy representation

Model posts with a privacy policy object (visibility level, allowlist, denylist, group IDs). Store friendship edges and group memberships in a graph store. Consider precomputing audience sets for common visibility levels (public, friends, friends-of-friends) to speed up reads.

3. Design read path with caching

For feed reads, use a cache of precomputed visible post IDs per viewer or per viewer segment. For direct URL access, check a cache of post privacy metadata and viewer relationship, falling back to the source of truth. Use consistent hashing and multi-level caching to handle high throughput.

4. Design write path and cache invalidation

On privacy setting changes, invalidate or update affected cache entries. On friendship changes, update precomputed audience sets and invalidate caches for affected viewers. Use an event-driven pipeline (e.g., Kafka) to propagate changes asynchronously, with a versioning scheme to avoid stale reads.

5. Discuss trade-offs and failure handling

Compare strong vs. eventual consistency for privacy changes, and explain how to handle cache misses, hot keys, and failures. Propose monitoring and auditing to ensure privacy rules are never violated.

Key Points to Mention

Separation of post content and privacy metadata to allow independent scaling and caching.
Precomputation of audience sets for common visibility levels (public, friends, friends-of-friends) to reduce read-time computation.
Use of a graph store (e.g., TAO) for efficient friendship and group membership lookups.
Cache invalidation strategies on friendship or privacy changes, such as versioned cache keys or event-driven invalidation.
Consistent enforcement of privacy rules across feed and direct URL access by centralizing logic in a privacy service.
Trade-offs between consistency and latency, and how to handle edge cases like denylist overriding allowlist.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.