Escaping The Frontend Collapse Pattern

Frontend codebases have a characteristic failure pattern. It is not a sudden collapse. It is a slow accumulation. A component that was meant to display a product card also fetches the product, manages loading state, handles add-to-cart, and tracks analytics. It works. The deadline was met. Four months later, the pattern has spread. Nobody is sure which component is responsible for which behaviour. Eight months later, a designer wants to change the card layout and the change breaks the cart. Fourteen months later, the team says the codebase needs a rewrite. The actual problem is not the code. It is the architecture. No one decided what each component was responsible for. The decision was never made; the default was entropy. This is the preventive architecture. The responsibility pyramid. The dependency direction rule. The four types of state. The API boundary. The frontend domain model. Error handling as architecture. File structure as architecture. The decisions that, made early, prevent the collapse. The decisions that, deferred, guarantee it. This is a synthesis review: source material generated with LLMs, reviewed and annotated with Notebook LLM, then edited for technical accuracy. The process is documented, not hidden. https://docs.google.com/document/d/1I... KEY TAKEAWAYS Frontend systems do not collapse suddenly; they degrade through accumulated responsibility gaps Every component has one job; mixing responsibilities produces components nobody can change safely Dependencies flow downward only; any import that goes up the pyramid is a design error Server state is not application state; data from an API belongs in a server state cache Fetch close to where it is used; a component that needs data should fetch it The API boundary is a contract; every fetch call belongs in a typed API module The frontend has its own domain model; API responses are not view models Error handling is architecture; deciding which layer handles which error is a design decision File structure encodes architecture; a flat components folder is a choice to have no architecture The cost of a flat component hierarchy is discovery cost, change cost, cognitive cost, and onboarding cost The pyramid is not a folder structure; it is a conceptual model Route controllers compose; pages orchestrate; features implement workflows; entities display; primitives provide The four types of state are server, application, UI, and derived; each has a distinct home State ownership rules prevent the two-store problem and the ghost-state problem The cache layer is the bridge between the upward and downward flows Mutation success invalidates the cache; the downward flow handles the update Optimistic updates are appropriate for fast, high-success operations; not for financial transactions The design system is the shared layer of the frontend architecture Tests should verify user behaviour, not implementation details Observability data guides refactoring priority The collapse pattern is preventable; the decisions that prevent it must be made early WHO THIS IS FOR Frontend engineers, full-stack engineers, tech leads, engineering managers, and anyone who has ever said "this codebase needs a rewrite" when the actual problem was that no one decided what each component was responsible for. RELATED Frontend architecture, frontend collapse pattern, component responsibility pyramid, route controllers, page components, feature components, entity components, primitive UI components, dependency direction, Feature-Sliced Design, FSD, state architecture, server state, application state, UI state, derived state, React Query, TanStack Query, state ownership, data flow, API boundary, typed API modules, view models, frontend domain model, error handling architecture, error boundaries, query error states, performance architecture, code splitting, route-based splitting, bundle architecture, Core Web Vitals, security boundaries, design system, design tokens, testing strategy, observability, production frontend systems. CORRECTIONS If something here is wrong or outdated, say so in the comments. Corrections get pinned and folded into the written version. SUBSCRIBE New synthesis reviews on systems, music, and language process: [CHANNEL LINK] #FrontendArchitecture #systemsengineering #llmreview