Question 1

What is a request lifecycle, and why should a backend engineer know it for their framework?

Accepted Answer

Summary

The request lifecycle is the ordered sequence of steps a framework runs for each HTTP request: server hand-off, bootstrap, middleware or filters, routing, authentication and validation, the controller or view, response creation, the response passing back out, and post-response work. Knowing it tells you where to put each piece of logic and explains many production bugs.

Longer Answer

Ordering bugs are common: middleware that runs before the user is loaded, exceptions raised in a layer the error handler doesn't cover, guards that see unvalidated input, expensive bootstrap work paid on every request, or state leaking between requests in long-running workers. Each framework names the stages differently, but the shape is the same.

Key Points

Ordered steps from server hand-off to post-response work.
Tells you where cross-cutting logic belongs.
Explains ordering and error-handling bugs.
Same shape, different names per framework.

Deep dive: Request Lifecycle: The Anatomy of a Request

Question 2

What layers does a request pass through before reaching application code, and how should their timeouts relate?

Accepted Answer

Summary

Typically client → CDN or load balancer → reverse proxy or web server (nginx, Apache) → application server (PHP-FPM, Gunicorn/Uvicorn, Node.js, Tomcat) → framework pipeline → your code and its outbound calls. Inner timeouts should be shorter than outer ones, so the innermost layer gives up first, returns a meaningful error and stops the work.

Longer Answer

If an outer layer times out first, users see a generic 504 while inner layers keep working and logging success, and retries multiply the load. Propagate a request ID or W3C trace context through every layer to correlate logs.

Key Points

CDN/LB → web server → app server → framework → code.
Inner timeouts shorter than outer ones.
Outer-first timeouts waste work and confuse logs.
Propagate request IDs end to end.

Deep dive: Request Lifecycle: The Anatomy of a Request

Question 3

Where should authentication, authorisation, validation and error formatting live in a web framework?

Accepted Answer

Summary

Authentication in the pipeline layer that runs for every request (middleware, firewall, guard, filter, dependency); coarse authorisation in route-level middleware, guards or dependencies with default-deny; resource-level authorisation near the data (services, policies, query scopes); validation at the input boundary (Form Requests, serializers, Pydantic models, pipes, @Valid); error formatting in one global handler (exception handler, kernel.exception, exception filters, @ControllerAdvice).

Longer Answer

Putting checks inside each controller by hand makes them opt-in, and one forgotten endpoint becomes a data leak. A route-inventory test that fails when a route has no authorisation rule enforces default-deny.

Key Points

Authentication in the global pipeline.
Default-deny coarse authorisation.
Resource checks near the data.
One global error formatter.

Deep dive: Request Lifecycle: Choosing the Right Layer for Cross-Cutting Concerns

Question 4

Walk through the Laravel request lifecycle and say where you would add code that must run on every request.

Accepted Answer

Summary

public/index.php loads the autoloader and app; the HTTP kernel bootstraps (environment, configuration, error handling, facades) and registers then boots all service providers; global middleware runs; the router matches a route and applies its middleware group and route middleware; the controller runs; the response passes back through middleware in reverse and is sent; terminable middleware runs afterwards. Code for every request goes in global middleware; wiring goes in service providers, kept cheap.

Longer Answer

Under PHP-FPM, providers boot on every request, so queries or HTTP calls in boot() slow down everything; under Octane they boot once per worker, so request data must not be captured in singletons.

Key Points

Bootstrap → providers register/boot → middleware → router → controller.
Response back through middleware, then terminate.
Every-request code in global middleware.
Keep providers cheap.

Deep dive: Request Lifecycle: The Laravel Request Lifecycle

Question 5

Walk through the Django request lifecycle.

Accepted Answer

Summary

WSGI/ASGI handler builds HttpRequest → MIDDLEWARE in order (request phase) → URL resolver → process_view hooks → view → process_exception on errors or template response rendering → MIDDLEWARE in reverse (response phase) → request_finished signal.

Longer Answer

Middleware that uses request.user must come after AuthenticationMiddleware, which needs SessionMiddleware. process_view can short-circuit before the view (CSRF does).

Key Points

Middleware down, resolver, process_view, view.
process_exception and template rendering.
Middleware up, request_finished.
Ordering dependencies matter.

Deep dive: Request Lifecycle: The Django Request Lifecycle and Middleware Order

Question 6

How does Express handle a request, and how are errors routed?

Accepted Answer

Summary

Middleware and route handlers run in registration order; each responds or calls next(). next(err) or a synchronous throw skips to error-handling middleware (functions with four parameters). Unmatched requests get a 404. Express 4 ignores rejected promises from async handlers; Express 5 forwards them to error handlers.

Longer Answer

Register error handlers last, with four parameters, and never send a response twice.

Key Points

Registration order; next() continues.
Four-parameter error handlers.
Express 5 handles async rejections.
404 when nothing responds.

Deep dive: Request Lifecycle: Express: The Middleware Stack and Error Handling

Question 7

What is the NestJS request lifecycle?

Accepted Answer

Summary

Middleware → guards → interceptors (before) → pipes → controller handler (and services) → interceptors (after) → response; exception filters handle errors thrown at any stage. Within each kind, global ones run before controller-level and route-level ones (pipes also apply per parameter).

Longer Answer

Because guards run before pipes, a guard sees the raw request, not the validated and transformed DTO. Use guards for identity and coarse permissions and do resource-level checks after validation.

Key Points

Middleware, guards, interceptors, pipes, handler.
Interceptors wrap the handler (before and after).
Exception filters catch errors from any stage.
Guards see raw input.

Deep dive: Request Lifecycle: NestJS: Middleware, Guards, Interceptors, Pipes and Filters

Question 8

Describe the Spring MVC request flow and where exceptions are handled.

Accepted Answer

Summary

Filter chain (including Spring Security) → DispatcherServlet → HandlerMapping → HandlerInterceptor.preHandle → argument resolution, message conversion and @Valid → controller → return value written (or view rendered after postHandle) → afterCompletion. Exceptions thrown inside the DispatcherServlet are handled by exception resolvers such as @ControllerAdvice; exceptions in filters are not.

Longer Answer

For authentication errors in Spring Security, use AuthenticationEntryPoint and AccessDeniedHandler to keep the API's error format.

Key Points

Filters → DispatcherServlet → interceptors → controller.
Message converters and validation.
@ControllerAdvice inside MVC only.
Security handlers for filter-level errors.

Deep dive: Request Lifecycle: Spring Boot: Filters, DispatcherServlet and Interceptors

Question 9

What is the middleware 'onion' model?

Accepted Answer

Summary

Each middleware wraps the rest of the pipeline: it runs code on the way in, calls the next layer, then runs code on the way out with the response. Request-phase code runs in registration order and response-phase code in reverse order. Laravel, Django, Express/Koa, Starlette, ASP.NET Core and PSR-15 middleware all follow it.

Longer Answer

The model explains why a logging middleware placed outermost sees every response (including errors produced inside), why middleware can short-circuit by returning a response without calling the next layer, and why order determines what each middleware can see.

Key Points

Wraps the next layer: in, next, out.
In: registration order; out: reverse.
Can short-circuit.
Order defines visibility.

Deep dive: Request Lifecycle: The Django Request Lifecycle and Middleware Order

Question 10

Describe Symfony's HttpKernel lifecycle and how listener priorities affect it.

Accepted Answer

Summary

The kernel dispatches kernel.request (session, routing, locale, firewall and your listeners; any may set a response), kernel.controller and kernel.controller_arguments, runs the controller, kernel.view for non-Response results, kernel.response, kernel.finish_request, sends the response, then kernel.terminate; kernel.exception handles errors. Listeners run from highest to lowest priority, and setting a response stops later listeners.

Longer Answer

A maintenance listener with default priority runs after routing and the firewall, so visitors get a 404 or login redirect instead of the maintenance page; give it a higher priority. Inspect the order with bin/console debug:event-dispatcher kernel.request.

Key Points

Events: request, controller, controller_arguments, view, response, finish_request, terminate, exception.
Higher priority runs first.
Setting a response short-circuits.
Inspect with debug:event-dispatcher.

Deep dive: Request Lifecycle: Symfony's HttpKernel and Kernel Events

Question 11

Describe how FastAPI processes a request and where exceptions are handled.

Accepted Answer

Summary

ServerErrorMiddleware (outermost) → user middleware (last added runs first) → ExceptionMiddleware with your handlers → router → dependency resolution and Pydantic validation (422 on failure) → endpoint → response serialisation → dependency exit code and background tasks. Exceptions inside the ExceptionMiddleware layer use your handlers; an HTTPException raised in user middleware becomes a 500.

Longer Answer

Put authentication in dependencies, keep middleware for global protocol concerns, and never block the event loop inside async def endpoints.

Key Points

Server errors → middleware → exception handlers → router.
Dependencies and validation before the endpoint.
HTTPException in middleware → 500.
Auth in dependencies.

Deep dive: Request Lifecycle: FastAPI and Starlette: Middleware, Exceptions and Dependencies

Question 12

What happens in the browser from navigation to an interactive single-page app?

Accepted Answer

Summary

DNS, TLS and the HTML request; parsing HTML and downloading CSS and JavaScript; the framework renders the app (or hydrates server-rendered HTML); effects or mounted hooks run and often start data requests; components re-render with data. Client-side navigations then change routes without full reloads, running router guards or loaders.

Longer Answer

Fetching in nested effects creates request waterfalls; load data at the route level and in parallel. Hydration mismatches happen when server and client render different output.

Key Points

Navigation → HTML → assets → render/hydrate.
Effects after render start fetches.
Router guards/loaders on navigation.
Avoid waterfalls and mismatches.

Deep dive: Request Lifecycle: The Browser Side: React and Vue Page Loads