The Data Layer as a First-Class Architecture Decision

The plain-language idea

Picture a codebase where every component that needs data reaches for whatever felt convenient at the time it was written: one component calls a raw fetch directly, another wraps it slightly differently, a third pulls in a data-fetching library nobody else on the team uses. Each individual decision was reasonable in isolation. The accumulated result isn't.

Treating every data-fetching call site as its own independent decision produces a real, compounding cost, not a theoretical one:

• Inconsistent loading and error UX. One screen shows a spinner, another shows nothing until data arrives, a third silently swallows errors — not because anyone chose that inconsistency, but because nobody chose anything at the level of the whole app.
• Duplicated auth-token-attachment logic. Every call site that independently decided how to fetch also independently decided how to attach an auth token, refresh an expired one, and handle a 401 — the same problem solved slightly differently N times, with N chances to get it slightly wrong.
• Cache invalidation bugs from components that don't know about each other. Two components fetching the same underlying record through two different, uncoordinated paths have no way of knowing the other one exists — one updates it, the other keeps showing stale data, and nothing in the system was ever responsible for keeping them in sync.

See it in a real thing: the same answer, decided once

Every lesson in this track was really answering one piece of a single larger question: what does this app's data layer do, consistently, everywhere?

• How do loading, success, error, and empty states render — decided once, not reinvented per component.
• How do requests that don't depend on each other get fired — in parallel, not accidentally staircased into a waterfall.
• How does a mutation update the UI and invalidate whatever else was showing the same data — one shared answer, not "however this component's author happened to handle it."
• How does an auth token get attached, and what happens when the API is shaped in a way that's painful to consume — solved at the boundary, not patched around at every call site that hits it.

None of those are framework features. They're architectural decisions — the kind normally reserved for "how do we structure our components" or "how do we manage state" — applied to data fetching instead. A team that makes them once, deliberately, and applies the answer everywhere ends up with genuinely less code and far fewer categories of bug than a team that lets each new feature reinvent its own answer.

What people usually miss

Watch out

• "We don't have a data layer" almost always means "we have twenty of them," not zero. Every ad hoc fetch call site that solved loading/error/caching/auth its own way is a tiny, uncoordinated data layer of its own — the absence of one deliberate design doesn't mean the app has no data layer, it means it has too many disagreeing ones.
• This doesn't require adopting any particular library. The architectural decisions (one loading-state model, one auth-attachment strategy, one invalidation approach) are real whether they're implemented with a dedicated library, a small in-house wrapper, or plain fetch used consistently — the consistency is the point, not the tool.
• Retrofitting consistency onto an existing inconsistent codebase is real, gradual work, not a single refactor. A team recognizing this problem late doesn't fix it by rewriting every call site at once — it fixes it by making new call sites follow the shared answer and migrating old ones opportunistically.
• The cost of not deciding is invisible until the app has enough data-dependent features for the inconsistencies to collide. A small app with three fetches genuinely doesn't need this — the cost shows up specifically once components sharing underlying data multiply, which is exactly why it's easy to under-invest in early and expensive to retrofit late.

Why this matters in interviews

"How would you structure data fetching across a large application?" is a real, senior-leaning question, and the answer that actually lands is naming the recurring decisions — loading/error consistency, auth attachment, caching and invalidation — as one coherent architectural choice made once, rather than describing a library name as if picking a tool were the whole answer.