The backend is the server-side part of a web application: the code, services and data stores that run outside the user’s browser and decide what the application actually does. In web architecture, the backend receives requests, applies business rules, reads and writes data, and returns responses, either as finished HTML pages or as structured data for the frontend.
The boundary between backend and frontend is a trust boundary. Anything running in the browser can be inspected and modified by the user, so authoritative decisions about identity, permissions, prices and stored data belong on the backend. The term covers a single server process as well as a fleet of services, queues and databases.
What the backend does in a web application
A backend turns an incoming HTTP request into a trustworthy result. It authenticates the caller, checks what that caller may do, validates input, runs domain logic and persists the outcome. The response is then rendered as HTML or serialized as JSON and sent back through the network.
The table below lists the core responsibilities that almost every backend carries, regardless of language or framework.
| Responsibility | What it covers | Typical building blocks |
|---|---|---|
| Routing and API | Mapping URLs and methods to handlers | REST endpoints, GraphQL resolvers, RPC services |
| Authentication | Proving who the caller is | Sessions, OAuth 2.0, OpenID Connect, tokens |
| Authorization | Deciding what the caller may do | Roles, policies, ownership checks |
| Business logic | Rules of the domain | Pricing, workflows, calculations |
| Persistence | Storing and querying data | Relational databases, document stores, object storage |
| Integration | Talking to other systems | Payment gateways, email services, message queues |
| Background work | Tasks outside the request cycle | Job queues, schedulers, workers |
Layers and components of a backend
Behind a single domain name, a production backend is usually a chain of layers, each with a narrow role. Requests pass through edge services before reaching application code, and the application relies on storage and caching below it.
- Edge layer: DNS, CDN, TLS termination and a reverse proxy or load balancer distribute traffic and filter abuse.
- Application layer: stateless processes run the framework code, ideally so that any instance can serve any request.
- Cache layer: in-memory stores keep frequently read data close to the application and cut database load.
- Data layer: databases provide durability and transactions; their consistency guarantees shape what the application can promise.
- Asynchronous layer: queues and workers handle slow tasks such as image processing or sending email.
Keeping the application layer stateless is the key to horizontal scaling. Session data, uploads and locks move to shared stores, so new instances can be added or removed without losing user state.
Backend compared with frontend and full stack
Backend, frontend and full stack describe where code runs and who owns it, not a quality level. The comparison clarifies how responsibilities split in a typical web project.
| Aspect | Backend | Frontend | Full stack |
|---|---|---|---|
| Runs on | Servers, containers, serverless platforms | The user’s browser | Both |
| Trust level | Trusted environment | Untrusted, user-controlled | Must respect both |
| Main concerns | Data integrity, security, scalability | Usability, rendering, accessibility | End-to-end feature delivery |
| Typical languages | Java, C#, Go, Python, PHP, JavaScript | HTML, CSS, JavaScript, TypeScript | A combination |
| Failure impact | Affects all users and stored data | Usually affects one session | Varies |
In a headless architecture, the backend exposes content or commerce data only through APIs, and one or more frontends consume it. The backend-for-frontend (BFF) pattern adds a thin server layer per client type, shaping API responses for the web or a mobile app without bloating the core services.
Architectural styles and how to choose
There is no universally best backend style; the right choice follows team size, traffic profile and the rate of change. Splitting a system too early often creates more coordination cost than it removes.
| Style | Strength | Main cost | Good fit |
|---|---|---|---|
| Monolith | Simple deployment and debugging | Coupling grows with size | Small to mid-size teams and products |
| Modular monolith | Clear boundaries in one deployable | Requires discipline | Growing products not ready to split |
| Microservices | Independent scaling and releases | Network failures, distributed data | Many teams with separate domains |
| Serverless functions | No server management, pay per use | Cold starts, execution time limits | Event-driven or spiky workloads |
Latency targets also guide design. Many teams aim for server response times under about 200 ms for interactive requests, because Time to First Byte feeds directly into page load metrics. Slow operations should move to background jobs with status updates rather than blocking the request.
Common backend risks and mistakes
Most serious backend incidents come from a small set of recurring mistakes. Security issues dominate because the backend guards the data of every user at once.
| Mistake | Consequence | Remedy |
|---|---|---|
| Trusting client-side validation | Manipulated requests change data | Validate and authorize every request on the server |
| Building SQL from strings | SQL injection | Parameterized queries or a safe query builder |
| N+1 database queries | Slow pages under load | Batch loading and query review |
| Secrets in source code | Credential leaks | Secret managers and environment injection |
| No timeouts on external calls | Cascading outages | Timeouts, retries with backoff, circuit breakers |
In plain words
Think of a restaurant. The dining room, the menu and the waiter are the frontend: what guests see and touch. The kitchen, the pantry and the cash register in the back office are the backend: where the real work happens and where the records are kept.
Guests never walk into the kitchen, and they cannot change the bill themselves. In the same way, the backend makes the decisions that users must not control, such as who is logged in, what something costs and what is saved.
A real-world example
A mid-sized online bookstore runs its backend as a modular monolith behind a load balancer, with a relational database for orders and an in-memory cache for the catalog. During a seasonal sale, traffic rises to about ten times the normal level.
Because the application instances are stateless, the operations team adds instances within minutes. Catalog reads are served mostly from the cache, and order confirmation emails move to a background job queue, so checkout requests stay fast. The payment provider is called with a strict timeout and a retry policy. The sale completes without downtime, and no order is lost even when the email service briefly fails.