Normalizing Nested API Responses

The plain-language idea

A typical nested API response embeds related data inline. A list of blog posts, each with its full author object copied inline, is a common shape — and a real problem: if ten posts were written by the same author, that author's name, avatar, and bio are duplicated ten separate times in the response. If that author later changes their display name, every one of those ten independently-stored copies needs updating separately, or the UI shows a different name for the same person depending on which post happens to be on screen.

Normalization is the concrete fix: walk the nested response once and restructure it into a flat lookup, organized by entity type and id — something like { posts: { byId: {...}, allIds: [...] }, authors: { byId: {...} } }. Each post keeps only the author's id, not the full embedded object. Reading a post's author back out means looking it up by that id in the authors table. Because every post referencing the same author id points at the exact same single stored record, updating that one record makes every post referencing it correct automatically — there's nothing else to update, because nothing else was ever storing its own separate copy.

See it in a real thing: a list of posts with embedded authors

// Raw nested response — the same author object duplicated per post
const raw = {
  posts: [
    { id: "p1", title: "Intro to caching", author: { id: "a1", name: "Priya Shah" } },
    { id: "p2", title: "Cache invalidation", author: { id: "a1", name: "Priya Shah" } },
  ],
};

// Normalized: entities flattened into by-id tables, posts reference authors by id only
function normalize(data: typeof raw) {
  const authorsById: Record<string, { id: string; name: string }> = {};
  const postsById: Record<string, { id: string; title: string; authorId: string }> = {};

  for (const post of data.posts) {
    authorsById[post.author.id] = post.author;
    postsById[post.id] = { id: post.id, title: post.title, authorId: post.author.id };
  }

  return { posts: { byId: postsById, allIds: data.posts.map((p) => p.id) }, authors: { byId: authorsById } };
}

Two posts, each embedding its own full copy of the same author object — duplicated data.

BackNext

Rendering a post now needs a small join step instead of one direct read: authors.byId[posts.byId[postId].authorId]. That's the real cost — denormalized data reads back out in one step; normalized data needs a lookup. What it buys back: updating authors.byId["a1"].name once updates the name everywhere a1 is referenced, because every reference points at that same single record instead of an independent copy.

What people usually miss

Watch out

• Normalization trades a cheap read for a cheap update. Denormalized (nested) data is fast and simple to render directly; normalized data requires a lookup/join at render time, in exchange for making an update touch exactly one place instead of every duplicate.
• The bug normalization prevents is a real, visible UI inconsistency, not a theoretical one. Without it, the exact same entity can legitimately show different values in different parts of the same screen, depending on which nested copy happened to get updated and which didn't.
• allIds alongside byId isn't optional decoration. A plain object's key order isn't a reliable source of display order, so a normalized list still needs an explicit array of ids to know what order to render in.
• This is worth doing manually only when duplication is real. An app with entities that rarely repeat across responses (or a data-fetching library that already normalizes internally) gets little benefit from hand-rolling this structure.

Why this matters in interviews

"How would you structure client-side state for a list of posts, each with an author, so that an author update stays consistent everywhere?" is a real question that tests whether a candidate reaches for normalization deliberately, with a clear account of what it costs at read time, rather than either not knowing the pattern or applying it reflexively everywhere.