One Rename, 40,000 Writes

Roughly 40,000 writes — every document that embedded her old name has to be updated.

The whole point of denormalizing the display name onto every post/comment was to make reads cheap: a single-document fetch, with zero joins, that scales horizontally with no fan-out. But it inverts the cost of the one write that touches that shared fact — a rename that would be a single-row UPDATE users SET display_name = ... in a normalized relational schema instead requires touching every document that ever copied the old value. For a light poster that's nearly free; for a 40,000-post power user, it's a bulk operation across tens of thousands of documents, typically run as an asynchronous background job rather than one atomic write, since document stores generally don't offer cheap, all-or-nothing transactions across that many documents.

This is the denormalization trade-off in its cleanest form: you pay once per read, or once per write — never both for free — and it inverts specifically as a function of how many documents embed the duplicated fact, which grows with an active user's history, not with how often they rename. The mitigation isn't "never denormalize" (the read-side win is often exactly the right call): it's denormalizing deliberately, with an explicit answer to "what happens when this value changes" — either accept eventual, lazily-corrected staleness (old posts keep showing the old name for a while, which many products genuinely find acceptable, even expected) or keep the frequently- changing attribute normalized with a lookup at read time, reserving denormalization for facts that are effectively immutable once written.