How a Backend Processes a Request

The short answer

Once an HTTP request reaches a backend application, the application must decide which code should handle it, understand and validate its input, establish identity and permissions when required, apply business rules, call data stores or other services, and construct a response.

Frameworks arrange these responsibilities differently. Not every request reaches every stage, and the order can vary. The durable skill is recognizing each responsibility and the evidence that tells you where a request stopped.

Where this lesson begins

This lesson begins when an HTTP-speaking infrastructure component has passed the request to the application. DNS, transport, TLS, a CDN, load balancer, and reverse proxy may already have done work.

A reverse proxy can route /api traffic to an application service. The application then performs application routing: it matches POST /api/orders to the code responsible for creating orders. These are separate decisions, even if both use paths and both are casually called routing.

An earlier component may also return a response without contacting the application. A CDN can serve a cached response, a gateway can reject an oversized request, or a proxy can report that no healthy upstream is available. Receiving an HTTP status does not by itself prove that application code ran.

Application server and runtime

The backend runs inside a runtime or application server. It listens for work directly or receives work from another server, turns the incoming protocol data into framework request objects, invokes application code, and helps turn the result into an HTTP response.

Node.js with Express, a Java server running Spring MVC, a Python application behind a WSGI or ASGI server, and a serverless function can all fill this role. Their process, thread, event-loop, and deployment models differ. None changes the basic responsibility: run application code for an accepted request.

Routing the request

An application router commonly considers an HTTP method and a path pattern:

• GET /api/orders/9001 can select a read handler;
• POST /api/orders can select a create handler;
• DELETE /api/orders/9001 can select a delete handler.

Express associates route methods and paths with callback functions.Express routing is one concrete implementation, not a universal framework structure.³ Spring MVC uses a central DispatcherServlet that delegates request mapping, handler invocation, exception resolution, and other work to configured components.Spring demonstrates how the same responsibilities can be organized through a front controller.⁴

If no route matches, the application may return 404 Not Found. If a path exists but does not support the method, it may return 405 Method Not Allowed. Infrastructure can produce either status too, so logs and configuration determine which component answered.

Middleware, filters, or interceptors

Frameworks often provide a pipeline for concerns shared across handlers. Names include middleware, filters, interceptors, hooks, or policies.

Shared stages may:

• attach a request identifier;
• parse content;
• enforce size limits;
• establish an authenticated identity;
• apply cross-origin policy;
• record timing and logs;
• catch errors and translate them into responses.

Express middleware can inspect or change request and response objects, end the response, or pass control to the next function.The Express guide shows one chain-of-functions model.² Another framework may build the same concerns into annotations, dependency injection, decorators, or a central dispatcher.

Middleware does not always run “before the handler and then disappear.” It can perform work after downstream code returns, or it can return early so the handler never runs.

Parsing the request

HTTP presents bytes and fields. The application needs useful values. A JSON parser can turn request content into an object; a URL parser can expose query parameters; route matching can extract an order identifier.

Parsing asks questions such as:

• Does the content follow JSON grammar?
• Can this path segment be interpreted in the expected form?
• Does the declared media type have a supported parser?

A malformed JSON document can fail here, before business logic runs. Parsing is not validation: { "quantity": -3 } may be valid JSON while being unacceptable order input.

Validating input

Validation asks whether parsed input has an acceptable shape and meaning. For POST /api/orders, the application might require a non-empty list of product identifiers and positive integer quantities.

Syntactic validation checks form: type, length, range, pattern, or required fields. Semantic validation checks whether a value makes sense in context: a delivery date follows the order date, or a referenced product is available to order. OWASP recommends validating as early as practical and performing security-relevant validation on the server, where a client cannot bypass it.The OWASP Input Validation Cheat Sheet distinguishes syntactic and semantic checks.⁵

Frontend validation can improve usability, but it cannot establish trust. A caller can construct requests without using the frontend.

Authentication

Authentication asks: who is making this request?

The application might validate a session cookie, an access token, a client certificate, or another credential. A successful result usually produces an identity and related context. It does not yet prove that the identity may place this particular order.

Some public routes require no authenticated identity. Authentication may run in middleware before routing, after routing for selected endpoints, or inside a handler. The OWASP Authentication guidance covers identity proofing, credentials, sessions, and reauthentication considerations.Authentication establishes an identity claim; it is not the permission decision itself.⁶

Authentication and Sessions develops this stage into a complete login-to-logout model.

Authorization

Authorization asks: may this identity perform this action on this resource?

For an order request, a normal customer may create an order for their own account but not for another customer. A support role may view limited order information but not change prices. The check can depend on records loaded during processing, so authorization is not always one early middleware step.

OWASP recommends denying by default, applying least privilege, and validating permissions on every request.Client-side hiding is not an authorization boundary.⁷ An authenticated requester can still be forbidden from an operation.

Business logic

Business logic expresses the application's rules. It decides what an operation means, not merely how to store data.

For an illustrative POST /api/orders, it may:

1. calculate totals under the current pricing rules;
2. check whether products can be ordered in the requested quantities;
3. apply limits or promotions;
4. decide the initial order status;
5. coordinate the records that must change together.

This example leaves payment, tax, shipping, fraud controls, and many production concerns out of scope. The point is that successful parsing and permission do not determine the business result.

Cache, database, and external-service calls

Business logic may request data through an ORM, query builder, repository, database driver, cache client, or service client. These are application-side tools; an ORM or repository is not the database itself.

A backend does not always query a database. It may answer from computed values or a cache, call another service, publish a message, or return early. It may also make several calls and still fail after one succeeds.

Each dependency creates a failure boundary: timeout, rejected connection, unavailable record, constraint violation, incompatible response, or exhausted connection pool. A successful query does not guarantee that later serialization or response delivery will succeed.

Transactions at a high level

When several database changes must succeed as a unit, the application may use a transaction. An order record and its inventory update should not appear as a successful half-completed operation.

In PostgreSQL's transaction model, commands inside a transaction are committed together or rolled back, and intermediate states are hidden from other transactions.PostgreSQL documents BEGIN, COMMIT, rollback, and all-or-nothing grouping.¹⁰ Exact guarantees and failure behavior depend on the database, transaction boundaries, and isolation settings.

A transaction usually covers work within one database system. It does not automatically make calls to a payment provider, message broker, and database one atomic operation.

Creating and serializing the response

The handler's result becomes an HTTP response. The application chooses a status, response fields, and optional content according to the API contract. A serializer may convert an order value into JSON.

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/9001

{
  "id": 9001,
  "status": "pending"
}

The response model should avoid unintentionally exposing internal fields, credentials, stack traces, or implementation details. Serialization can fail too—for example, because application data contains an unsupported value or custom conversion code throws.

Error handling

Errors need classification as well as logging. A malformed request, failed authentication, forbidden action, missing resource, business conflict, unavailable dependency, and unexpected code defect do not describe the same boundary.

RFC 9110 defines 500 Internal Server Error as a server response indicating that it encountered an unexpected condition preventing fulfillment.The status identifies a broad server-error category, not its root cause.¹ Returning 500 for every client mistake hides useful distinctions. Exposing raw exception details can leak information.

Frameworks often centralize error translation so handlers can raise typed errors and one layer consistently maps them to HTTP responses. The mapping remains application policy and must not overwrite valuable diagnostic context.

Logging, tracing, and request identifiers

Useful diagnostics connect events from the same request. A generated request or interaction identifier can appear in logs from the proxy, application, and dependencies. Distributed tracing represents the request path as related spans carrying shared context; OpenTelemetry defines traces, spans, trace identifiers, and context propagation for this purpose.A trace helps correlate stages but does not replace application logs or metrics.⁹

Good records answer: which operation, which stage, how long, and what outcome? They should not copy every value indiscriminately. OWASP advises excluding or sanitizing secrets, access tokens, passwords, connection strings, encryption keys, and payment-card data.The Logging Cheat Sheet also describes interaction identifiers for linking related events.⁸

Synchronous work versus background jobs

Some work must finish before the response can be correct: validating an order, determining whether it was accepted, and storing the authoritative result. Other work may continue asynchronously: generating a report, sending a notification, or processing a large media file.

A background job can shorten request latency and provide retry boundaries, but it introduces new states. The API may need to report that work was accepted rather than completed. Queues, workers, deduplication, and failure handling become part of the system.

Moving work to a job is therefore an architectural choice, not a universal fix for slow endpoints.

Common framework variations

The following is a useful flow, not a mandated implementation:

Authentication may happen before route-specific validation. Authorization may require a loaded database record. Caching may sit in a proxy, middleware, service, or repository. Controllers, services, repositories, handlers, functions, and resolvers are organizational patterns—not required network stages.

Common misconceptions

Debugging scenario

Knowledge check

What to learn next