F1 Graph Storage & TAO Internals

From event logs to the social graph

Dr. Wei: Today we are connecting two ideas: moving changes through an ordered event log, and serving up-to-date relationship data quickly when an application needs it. Even if you did not see the earlier lecture, the key point is simple: logs help us move updates reliably, but they are not the fastest way to answer lots of read queries.

Sam: So the log is for updates, but not for looking things up. What replaces it when we need fast reads of relationships?

Dr. Wei: That is where TAO comes in. It is designed to serve relationship queries in real time at large scale, while the log based pipeline ensures changes arrive in order and can be replayed. In the next slides, we will see how those two pieces fit together: one path moves change, the other path answers reads quickly.

Why graph storage matters

Dr. Wei: When you open a social app, the page is really a graph view: your profile, friends, likes, comments, and recommendations all translate into many small lookups.

Dr. Wei: Now put a concrete latency budget on it. If we want a roughly 200 millisecond p95 page load, and the page triggers on the order of 500 graph reads, the average per read has to be well under a millisecond once you include network, queuing, and retries.

Sam: Five hundred reads in one request is a lot. Is the takeaway that we must avoid anything that behaves like a join, because even small slowdowns will blow up the tail?

TAO data model: objects $+$ associations

Dr. Wei: When we talk about TAO’s data model, the key idea is that a social graph can be expressed with just two building blocks, and everything else is built on top of them.

Dr. Wei: First are objects: a typed entity with an identifier and a bundle of properties. Think of a user or a post, plus whatever metadata you want to store about it.

Sam: When you say properties, is that intended to be flexible, like a blob of key value fields, or is it more like a fixed schema per object type?

Worked example: a like becomes two edges

Dr. Wei: In TAO-style graph storage, a single product action often turns into multiple stored association records. The point is not to change the meaning of the action, but to make the common read paths fast and predictable at scale.

Sam: So we are intentionally duplicating edges for read efficiency. How do we avoid the forward and inverse versions drifting apart when failures happen?

Dr. Wei: Those two stored records may use different association types like LIKES and LIKED BY, but that difference is mainly for lookup and indexing. Semantically it is the same underlying relationship, duplicated so we can fan out efficiently in either direction, and then support both range reads for lists and count reads for totals. The safety contract is that the application issues one logical write that produces both physical rows; the operations are idempotent, and any rare mismatch is detected and repaired by background reconciliation.

The core TAO API is intentionally tiny

Dr. Wei: TAO keeps its core interface intentionally small, focusing on just a handful of operations that cover the common needs of a social graph store.

Sam: Is the small API mainly about performance, or is it also about forcing product teams into patterns that are cacheable and safe at scale?

Dr. Wei: That simplicity pays off operationally: a small API enables aggressive caching, makes performance more predictable, and helps keep latency stable even at very large scale.

Two-tier architecture: MySQL $+$ distributed cache

Dr. Wei: TAO is a caching and consistency system as much as a storage system.

Sam: When you say two-tier, should I picture the cache as a best effort accelerator, or as something the system depends on for correctness and read after write behavior?

Dr. Wei: The goal is to serve most reads from memory while still keeping a reliable source of truth, and to make sure updates do not silently drift apart between the two.

Quantifying the cache win (one simple model)

Dr. Wei: This equation is the interview move: connect a cache hit rate to expected latency.

Write-through $+$ read-after-write consistency

Dr. Wei: When people say a system “feels consistent,” they usually mean something simple: after I change something, I expect to see that change right away on my next read.

Sam: So read after write is really a user experience guarantee. Is it only guaranteed for the writer in the same region, or does TAO try to make it global?

Dr. Wei: A safer mental timeline is: the write is committed at the primary database as the source of truth, and the cache is then updated or invalidated synchronously so that a subsequent read that hits the cache reflects that committed value. Importantly, we do not acknowledge success based on cache-only state; if the cache step fails, the system retries or invalidates so reads fall back to the database rather than showing a write that was never durably committed.

Association lists: range and count are first-class

Dr. Wei: On this slide, the big idea is that an association list is treated like a first-class object in storage, not just a byproduct of querying edges. We want to read a slice of the list, and we also want to know how big the list is, and those are different needs with different performance costs.

Sam: If I can read the list, why not just count the items I get back and use that as the size?

Dr. Wei: Because reading a range is usually optimized for returning the most relevant items quickly, like the newest edges first, and it may only fetch a page. Getting the total size can require touching far more data, so systems keep a separate count that can be returned fast without scanning through the list.

Sharding and data placement (no cross-shard joins)

Dr. Wei: This is the simplest sharding function to reason about. Real systems use consistent hashing and rebalancing, but the ownership idea is the same.

Cross-region replication: strong locally, eventual globally

Dr. Wei: Let’s build an intuition for cross-region replication in TAO: why user reads can feel fast and consistent nearby, even though the world-wide system is not perfectly synchronized at every moment.

Sam: When a follower region is serving reads from a slightly stale copy, what do we usually tell product teams to expect: can users see their own writes, and can two users in different regions see different truth for a while?

Dr. Wei: Other regions act as followers. They can serve many reads locally for low latency, but their copies lag behind because replication is asynchronous. If a write arrives in a follower region, it is forwarded to the primary, and the result propagates back out over time.

Interview calibration: what to say, and what not to say

Dr. Wei: Let’s calibrate how to talk about TAO and graph storage in an interview setting: what kinds of statements read as strong, and what kinds sound vague or risky at Meta scale.

Sam: When an interviewer asks why not use a generic graph database, what is the crisp argument they are looking for: is it mainly latency, operational complexity, or the ability to cache predictable primitives?

Dr. Wei: As you answer, aim to sound concrete: name the tradeoffs you are making, what you would store, what you would cache, and how you would explain consistency expectations instead of hand-waving them away.

Exit ticket: unfriending as a full-system walkthrough

Dr. Wei: For this exit ticket, we will do a full-system walkthrough of a single, familiar action: one person unfriending another. The goal is to explain, end to end, what the system must do so the relationship data stays correct and the user experience makes sense.

Sam: Should I frame the walkthrough as two association deletes plus cache and database updates, and then talk about what each user sees if one side propagates later than the other?

Dr. Wei: Then reflect on what each user can observe right after the action. If the two directions of the relationship are updated at different times, what does user A see versus user B, and for how long. Your answer should connect the unfriending operation to the consistency story a real product would expose.

Thank you for watching!

Thanks for watching. Subscribe and share if you found this useful—see you next time!