In document data modeling, what is fan-out on write versus fan-out on read, and how do you choose?

## The two shapes Every denormalization decision is ultimately about *when* the work of assembling data happens. **Fan-out on write** does the work at write time. When a new fact appears — a post is published, a user changes their display name, a price is set — the writer immediately pushes copies of it into every document that will later need to read it. The classic example is a feed: publishing a post appends an entry to each follower's feed document. A later read of a feed is one lookup of one document, already assembled, with no per-read joins and a latency that barely depends on how complex the underlying relationships are. **Fan-out on read** does the work at read time. The fact is stored exactly once, in the document that owns it, and each read gathers it from the sources. Reading a feed means finding who the user follows, then querying recent posts from each of them, then merging. Nothing is duplicated, nothing can drift, and a change to a post is one write — but every read pays the assembly cost, and the cost grows with the reader's connections. ## The arithmetic Start with three numbers: how often the fact is written, how often it is read, and the fan-out factor — how many documents would hold a copy. A fact read a thousand times for every write, duplicated into a handful of documents, is an easy fan-out-on-write case: you pay a few extra writes to eliminate a thousand assemblies. A fact rewritten constantly and copied into hundreds of thousands of documents is the opposite: each source write becomes a storm of copy writes, and by the time the storm finishes the value may already have changed again. The dangerous middle is a fan-out factor that is *unbounded* — no maximum you can state — because the design works fine in staging and collapses on the largest real entity. ## Latency shape, not just total cost Fan-out on write converts a variable, connection-dependent read latency into a fixed one. That is often worth more than any total-work saving: a feed that reads in a few milliseconds regardless of whether you follow ten accounts or ten thousand is a product feature. It also moves the expensive work off the user-facing path — the copies can be written by a background consumer while the publisher's request returns immediately. Fan-out on read keeps writes trivial and predictable and makes reads the variable part, which is fine when reads are rare, internal, or already batched. ## The hybrid, and why it is the real answer Most production designs are hybrids, split on the property that breaks the arithmetic. The standard example is the celebrity account: fan out on write for ordinary users, and for the small set of accounts with enormous follower counts, do not write copies at all — read their recent posts live at read time and merge them with the precomputed part of the feed. The read path becomes "one assembled document plus a live query for a handful of high-fan-out sources", which keeps both the write storm and the read assembly bounded. The same split appears outside feeds: duplicate a team's name into member documents unless the team has a hundred thousand members, in which case read it. A second hybrid axis is *which fields* you copy. Copying a small, rarely-changing subset — an id, a display name, a thumbnail — gives most of the read benefit for a fraction of the sync obligation, while volatile fields stay behind a live read. ## What fan-out on write costs beyond writes Copies consume storage and cache space proportional to the fan-out, which can matter more than the write cost when the working set stops fitting in memory. They also create a permanent correctness obligation: every copy needs an owner, a bounded staleness, and a way to be found and repaired. And they raise a delivery question — if the copies are written asynchronously, the write is acknowledged before the reads are correct, so the propagation lag becomes a user-visible property you must measure. ## How to answer Name both shapes, state the three numbers that decide between them (write rate, read rate, fan-out factor), and add the two refinements that mark experience: latency shape matters independently of total work, and real systems go hybrid at the entities where the arithmetic breaks rather than picking one strategy globally.