How the interviewer opens it
“Design a service that controls who can view social posts. Support public, private, friends-only, and custom-audience posts, including blocks and later permission changes.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Visibility and identity
- Custom audiences
- Blocks
- Protected content
- Scale
- Traffic and read:write ratio
- Latency and regions
- Change completion
- Availability and durability
- Existing systems and update ownership
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Set and change a post's audience
- Authorize access to post text, media, and metadata
- Apply friendship changes, blocks, and custom audience changes
- Enforce current permissions across content caches and replicas
Usually out of scope
- Build the feed, search service, or media store
- Recommend friends or audiences
- Edit post content
- Remove content that a viewer already saved
- Control access to private messages
What interviewers ask about
- Relationships and audiences
- One relationship change can affect thousands of old posts. Blocks must override every audience without a separate update to each post.
- Access through content copies
- A correct authorization service cannot protect a post when another path serves the content without a check.
- Permissions after a change
- Independent caches can retain an allow decision after a successful change. Separate reads can also combine facts from incompatible states.
- Popular posts and outages
- One public post can receive most reads. Blocks still make access depend on the viewer, and failures cannot permit stale access.
Common mistakes
- Claims immediate revocation while allow decisions remain valid until cache expiry.
- Checks a post policy but ignores changes to friendship, blocks, or custom membership.
- Protects the feed API but leaves media URLs or content origins public.
- Updates every affected post after a block or friendship removal.
- Uses a stale replica when the authoritative permission store fails.
- Claims that revocation removes bytes that a viewer already received.
The bar by level
- Senior (L5/E5)
- Defines the revocation boundary. Uses atomic fact updates and current transactional reads. Covers custom audiences, media paths, retries, and denial during uncertain authorization.
- Staff (L6+/E6+)
- Explains which coordination strict revocation requires. Designs safe replica reads, hot-post capacity, and failover. Rejects incompatible availability promises and avoids revocation work per post.