04QuestionsMeta Post Privacy

04 · Worked prompt

Meta Post Privacy

Design audience policy evaluation, graph-aware authorization, caching, and privacy-safe fan-out.

30 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design audience policy evaluation, graph-aware authorization, caching, and privacy-safe fan-out.

Meta Post Privacy system architecture. Post and policy versions are authoritative; feeds contain candidates that must be re-authorized at read time. Request path: Social clients to API gateway to Post service to Post/policy DB. Asynchronous path: Post change log to Audience fan-out. Read path: Feed assembler to Feed candidate store. External dependency: Relationship graph. — Meta Post Privacy · system architecture

DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

Post and policy versions are authoritative; feeds contain candidates that must be re-authorized at read time.

INTERVIEW CONTRACT

Design audience policy evaluation, graph-aware authorization, caching, and privacy-safe fan-out.

CAPACITY QUESTIONS TO QUANTIFY

Read-heavy feeds · huge graphs · strict revocation SLO · policy cache pressure. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Social clients → API gateway
Publish + view feed enters over HTTPS / RPC. API gateway handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
API gateway → Post service → Post/policy DB
Post service receives the command, checks invariants and retry identity, then uses atomic policy version to update Post/policy DB. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Post service → Post change log → Audience fan-out → Feed candidate store
Post service emits publish after commit; Audience fan-out uses consume and project / update to build Feed candidate store. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
API gateway → Feed assembler → Feed candidate store / Post/policy DB
Feed assembler uses candidate page for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Feed assembler → Relationship graph
batch relationship check crosses into Relationship graph. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
API gatewayIdentity + abuse controls	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Post serviceCommit post + audience policy	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Post/policy DBVersioned content + rules	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Post change logFan-out and invalidation	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Audience fan-outResolve graph snapshot	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Feed candidate storeIDs, not disclosure truth	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Feed assemblerHydrate + authorize candidates	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
Relationship graphVersioned edges + blocks	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: SQL/distributed SQL stores posts and policies; a graph adjacency service stores relationships; Cassandra/Scylla stores feed candidate IDs.
Partitioning / sharding: Posts shard by post_id/author_id, graph edges by source user, and feed candidates by user_id plus a bounded time bucket.
Indexes: Author posts (author_id, created_at), policy (post_id, version), graph (source, target, edge_type), and feed cursor (user_id, score, post_id).
Replication + consistency: Post and current policy reads are strong. Feed candidates are eventual and must be re-authorized against current policy/relationship state.
Cache, queue + recovery: Fan-out writes candidate IDs only; privacy/delete changes publish versioned high-priority invalidations. Cache checks briefly with versions.
Capacity math: Estimate posts/sec, follower distribution, feed reads/sec, graph edges/user, privacy-check p99, and celebrity skew.
Alternative rejected: Fully authorized materialized feeds are fast but leak stale privacy; candidates plus read-time authorization preserve correctness.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Double enforcement

Filter at fan-out for efficiency and at read for current truth

Precomputation is never an authorization decision

Revocation

Publish high-priority policy events and version cache entries

TTL alone is not a defensible privacy SLO

Graph scale

Batch relationship checks and cache versioned edges without caching allow decisions forever

Authorization data has different freshness needs than ranking data

Failure pressure test

Show detection, containment, recovery, and evidence.

Policy service unavailable

Fail closed for uncertain content and degrade feed density

privacy-check failures

Stale feed candidate

Read filter removes it and schedules cleanup

filtered candidate ratio

Cache purge lag

Key by policy version so old allow results cannot validate new reads

old-version reads

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize create posts with audience rules and generate scalable feeds.”
Scale
“The design changes around read-heavy feeds · huge graphs · strict revocation slo · policy cache pressure.”
Decision
“Fan-out-time filtering is fast but stale; read-time checks are current but costly.”
Risk
“The first failure I want to pressure-test is: Blocks and privacy changes can leave unauthorized content in caches and feeds.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Create posts with audience rules
Generate scalable feeds
Apply blocks and privacy changes quickly
Prevent caches and search from leaking revoked content

Meta Post Privacy · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

draft

published

restricted

deleted

02Data model and APIs4 entities · 3 interfaces

Core entities

Postpost_id, author_id, body, policy_id, versionOwner: Post service

AudiencePolicypolicy_id, rule, versionOwner: Policy service

Relationshipsource_id, target_id, type, versionOwner: Graph service

FeedCandidateviewer_id, post_id, policy_versionOwner: Feed store

External interfaces

POST /v1/posts

Create content and an immutable policy version

PUT /v1/posts/{id}/audience

Create a new policy version and revocation event

GET /v1/feed?cursor={cursor}

Hydrate candidates and enforce current policy

03Deep dives and trade-offsChoose one

Double enforcement

Filter at fan-out for efficiency and at read for current truth

Precomputation is never an authorization decision

Revocation

Publish high-priority policy events and version cache entries

TTL alone is not a defensible privacy SLO

Graph scale

Batch relationship checks and cache versioned edges without caching allow decisions forever

Authorization data has different freshness needs than ranking data

04Failures, recovery, and evidence3 scenarios

Policy service unavailable

Fail closed for uncertain content and degrade feed density

privacy-check failures

Stale feed candidate

Read filter removes it and schedules cleanup

filtered candidate ratio

Cache purge lag

Key by policy version so old allow results cannot validate new reads

old-version reads

05What makes the answer seniorInterviewer signals

Say explicitly that feed storage contains candidates, not authorization grants
Privacy correctness outranks feed completeness
A staff answer quantifies revocation time and audit evidence
Primary trade-off: Fan-out-time filtering is fast but stale; read-time checks are current but costly.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Double enforcement

Revocation

Graph scale

Show detection, containment, recovery, and evidence.

Policy service unavailable

Stale feed candidate

Cache purge lag

Reference details

Core entities

External interfaces

Double enforcement

Revocation

Graph scale

Policy service unavailable

Stale feed candidate

Cache purge lag

Can you redraw it from memory?