Request Lifecycle: How Web Frameworks Handle a Request · Capstone Case Studies
Capstone: One API Standard Across Many Frameworks
A company runs Laravel, Django, NestJS and Spring Boot services. Design how each one enforces the same request IDs, authentication, error format and timeouts using its own request pipeline.
Scenario
Example company: after acquisitions, a platform team owns four services behind one API gateway: a Laravel billing service, a Django content service, a NestJS notifications service and a Spring Boot orders service. Clients complain that:
- error responses look different in every service,
- some services return 500 for expired tokens and others 401,
- support can't trace a request that crosses services,
- a slow downstream call in one service makes the gateway time out.
Requirements
- Every service accepts and propagates a request ID / trace context, and logs it.
- Every service validates the same JWTs and returns 401 for missing or expired tokens and 403 for missing permissions, in one shared error format (for example RFC 9457 problem details).
- Authorisation is default-deny in each service.
- Timeouts are aligned with the gateway's.
Constraints
- Each team keeps its framework.
- The gateway can validate tokens, but services must not trust requests that bypass it.
Deliverables
- For each framework, name the pipeline component you'd use for: request ID, authentication, authorisation, validation errors and error formatting (for example Laravel middleware and exception handler; Django middleware and DRF exception handler; NestJS middleware, guards, pipes and exception filters; Spring filters, Spring Security entry points and
@ControllerAdvice). - The traps from this course that apply to each (exceptions thrown in Spring filters, guards before pipes in NestJS, middleware order in Django, provider cost in Laravel).
- A shared contract test suite that every service must pass (status codes, error body, headers).
- The timeout budget from gateway to each service's outbound calls.
Hints
- Write the error format once as a specification and contract tests; implement it per framework.
- Generate the request ID at the gateway if missing; each service only propagates it.
- Shared libraries per language are fine, but the contract tests are what keep the services consistent.
Deliverables
Which pipeline components would you use in each framework for authentication and error formatting?
Model answer
Laravel: auth middleware and the exception handler; Django: middleware or DRF authentication classes and a custom exception handler; NestJS: a global auth guard and an exception filter; Spring: Spring Security filters with an AuthenticationEntryPoint/AccessDeniedHandler and @ControllerAdvice.
Rubric
Look for the correct layer per framework and awareness of each framework's traps (filters vs advice, guards vs pipes, middleware order).
How do you keep four services consistent over time?
Model answer
A shared written specification plus contract tests run in each service's CI (status codes, error body schema, headers, request-ID propagation), and gateway-level monitoring of response shapes.
Rubric
Strong answers rely on automated contract tests rather than conventions alone.
How do you design the timeout budget?
Model answer
Start from the client-facing deadline at the gateway, subtract margins per hop so each service's request timeout is shorter than the gateway's, and each outbound call's timeout fits within the service's remaining budget; propagate deadlines where possible.
Rubric
Look for inner-shorter-than-outer reasoning and deadline propagation.
Open in the app to mark lessons complete, take notes and track your progress.