Questions
5 of 5
What is the complete NestJS request lifecycle in order?
Difficulty: 5/10
request lifecycle, guards, interceptors
The full order is: Incoming request → Middleware → Guards → Interceptors (pre) → Pipes → Controller handler → Interceptors (post) → Exception Filters. Exception filters also catch exceptions thrown at any earlier stage. Middleware is the only layer that runs before routing and has no knowledge of which handler will be invoked.
Complete request lifecycle order:
- 1
- Incoming HTTP request hits the server.
- 2
- Middleware — runs before routing, has access to req/res, must call next().
- 3
- Guards — decide if the request is allowed to proceed (authentication/authorization).
- 4
- Interceptors (pre-controller) — transform or log before the handler runs.
- 5
- Pipes — validate and transform route params, query params, and body.
- 6
- Controller handler — executes your route method.
- 7
- Interceptors (post-controller) — transform the response on the way out.
- 8
- Exception filters — catch any unhandled exception and shape the error response.
Visualizing the pipeline in a single controller
Scenario Questions
0-2 years experience
- 1When an HTTP request arrives at a NestJS app, can you describe step‑by‑step what components handle it before the controller method runs?
- 2If you add a custom pipe to a controller method, at which point in the NestJS request lifecycle does it execute?
- 3What would you expect to see first: a guard or a middleware, and why?
2-5 years experience
- 1We introduced a global interceptor to transform responses, but some validation errors are still bubbling up unmodified. Which part of the lifecycle is likely causing this?
- 2During a bug we noticed a guard prevented a route from executing, yet the response still contained data. Explain how the order of guards, interceptors, and pipes could lead to that behavior.
- 3If you need to add authentication that should run before any validation pipes, where would you place the guard or middleware?
5-8 years experience
- 1Our microservice must log precise request timings with minimal overhead. Would you put the logger in middleware or an interceptor, and what trade‑offs does the lifecycle order introduce?
- 2You need to short‑circuit a request after authentication but before the controller logic runs. Which lifecycle hooks would you use, and how would you ensure downstream interceptors still behave correctly?
- 3When scaling to many concurrent requests, how does the order of exception filters relative to interceptors affect performance and error handling?
8+ years experience
- 1We are refactoring a large monolith into feature modules with shared global pipes and interceptors. How would you redesign the request lifecycle to keep global behavior while allowing module‑level overrides?
- 2From an architecture standpoint, how do you decide which concerns belong in middleware, guards, pipes, or interceptors given NestJS's request lifecycle and long‑term maintainability?
- 3If we need to support both HTTP and gRPC transports in the same codebase, how does the request lifecycle differ and what adjustments would you make to keep the pipeline consistent?
Follow-up Questions
- Can you walk me through a concrete example of a guard you wrote and when it runs?
- If you needed to log request duration, where in the lifecycle would you place that logic?
- What would happen if a pipe threw an error after the controller has already returned a value?