What is Backend?
Definition
The backend is the server-side part of a website or application that users never see directly. It enforces business rules, stores and retrieves data in databases, authenticates users, talks to external services such as payment providers or email gateways, and delivers results to the frontend or to mobile apps, usually through an API.
Also known as: back-end, back end, server side, server-side development
What happens out of sight
Click "Add to basket" on an online shop and the only visible change is a number on the basket icon. Behind it, stock is checked, prices and promotions are applied, the basket is saved and other systems may be notified. All of that is backend work, which breaks down into four broad jobs:
- Business rules — who gets a discount, when an order can still be cancelled, whether two bookings clash.
- Data — storing records consistently in a database and reading them back.
- Access control — establishing who the user is (authentication) and what they are allowed to do.
- Integrations — calling payment gateways, carriers, accounting software or a CRM.
Following one order through the server
When a customer presses "Place order", a typical backend goes through these steps:
- The HTTP request passes through a reverse proxy or load balancer and reaches an application server.
- The router hands it to the matching handler.
- The session or token is checked; unknown users are rejected right here.
- The payload is validated — are the address fields present, is the quantity sensible?
- The price is recalculated on the server, stock is decremented and the order is written inside a single transaction.
- Slow side effects, such as the confirmation email, are pushed onto a job queue so the customer doesn't wait for them.
- A JSON response with the order number goes back to the browser.
The frontend only ever sees that last step. The agreed shape of requests and responses between the two sides is the API.
Common building blocks
| Piece | Role | Examples |
|---|---|---|
| Language and runtime | Where the code is written and executed | Node.js, Python, Go, Java, PHP, C#/.NET |
| Framework | Ready-made routing, validation, sessions and similar plumbing | Express, Django, Laravel, Spring, ASP.NET Core |
| Database | Durable storage | PostgreSQL, MySQL, MongoDB |
| Cache | Fast access to frequently read data | Redis, Memcached |
| Queue | Moves long-running work out of the request cycle | RabbitMQ, SQS, Redis-backed queues |
| Web server / proxy | TLS, compression, static files, routing | Nginx, Caddy |
On most projects the choice of language matters less than the team's experience with it and the maturity of the libraries the work depends on.
The trust boundary sits here
Everything that runs in the browser is under the user's control. JavaScript can be edited, form fields bypassed and requests replayed by hand. Validation in the frontend is there for a smoother experience; the checks that actually protect anything must run on the server. A backend that reads the price from the request body, or returns a record without asking "may this user see this order?", is insecure no matter how carefully the interface was built.
Terms that get mixed up
A backend is not a machine. One server can serve the frontend files and run the backend code at the same time. "Backend" describes a layer of responsibility, not hardware.
BFF and BaaS mean different things. A "backend for frontend" is a thin server layer shaped around the needs of one particular client, such as a mobile app. "Backend as a service" refers to hosted platforms that rent out ready-made backend features like authentication, a database and file storage.
Not every site needs its own backend. A brochure site whose content rarely changes can be published as pre-built static files, with server-side code limited to a few tasks such as handling a contact form.