Frontend vs backend vs infra: who owns what

The split most people learn by getting it wrong first

"The whole app" isn't one thing to debug. It's three layers, and they fail in completely different ways: what the user sees, what decides whether they're allowed to do it, and what keeps both of those actually reachable. Mixing these up is the single most common reason a bug takes an hour instead of five minutes for someone newer to backend work - you end up staring at the wrong layer entirely.

FrontendBackend

Frontend

Shows information and turns clicks into requests.

• Renders the screen and decides what the user sees.
• Validates a form for fast feedback, which anyone can skip with dev tools.
• Holds nothing that has to survive a refresh.
• Can hide a button, but cannot enforce who is allowed to press it.

Frontend renders. It doesn't decide.

React components, CSS, whatever runs in the user's browser - its job is showing information and turning clicks into requests. That's it. It is not, and cannot be, a security boundary, because anyone can open dev tools and send whatever they want directly to your APIAPIA defined way for one piece of code to ask another to do something, without needing to know how it happens internally. Not a specific technology - a function signature, a library's exports, and a REST endpoint are all APIs., skipping the frontend entirely.

This one's worth being blunt about: if a "delete account" button is disabled in the UI for users under 18, and the backend doesn't also check age before deleting, you don't have a rule. You have a suggestion. Frontend validation is a UX nicety. The backend has to enforce the actual rule, every time, independent of whatever the frontend did or didn't check.

Backend decides

This is where "can this user do this" actually gets answered - is this discount code still valid, does this user own this record, does this transaction leave the books balanced. Everything from Phase 1 through Phase 4 of this curriculum - runtimes, protocols, databases, distributed systems - lives here. It's the layer with the actual rules in it.

Infra keeps it running, and it's easy to forget it exists until it doesn't

Servers or containers, load balancersLoad balancerA component that sits in front of multiple servers and distributes incoming requests across them, so no single machine gets overwhelmed and a crashed instance doesn't take the whole system down., DNSDNSThe system that turns a human-readable hostname into the numeric IP address computers actually use to route traffic. The internet's phonebook, distributed across a chain of servers rather than kept in one place., the pipeline that ships your code out, the alerts that page someone at 3am. A lot of backend engineers don't own this layer day to day. But not understanding it shows up in the code you write anyway - if you don't know your process can get killed and restarted without warning, you won't think to make startup and shutdown handle that gracefully. Phase 5 gets into this properly.

Which layer, when something breaks

• Data on screen is wrong, but the raw API response looks fine → frontend.
• The response itself is wrong, missing fields, or an error → backend.
• Nothing comes back at all, or it's wildly inconsistent request to request → infra, before you touch application code at all.

None of the three covers for a mistake in another one. Clever frontend code can't fix broken business logic, and no amount of infrastructure scaling fixes a bug that was never about capacity in the first place.

Titles blur these lines constantly in real companies - a "full stack" role might touch all three, a small team's one backend engineer might also be the one who configures the load balancer. The boundary described here is about the nature of the problem, not who's assigned to fix it. Knowing which layer you're in is useful even when you're the only person covering all of them.