NestJS Case Studies & Practical Application 2 — Questions and Answers
Question 1: A NestJS microservice needs to handle intermittent downstream failures gracefully. Which pattern combined with `@nestjs/axios` best implements retry logic?
- Use RxJS `retry` operator on the HTTP observable (Correct answer)
- Wrap calls in a try/catch with a while loop
- Use `setInterval` to poll until success
- Configure `keepAlive` on the HttpModule
Correct answer: Use RxJS `retry` operator on the HTTP observable
RxJS `retry` composes directly on observables returned by HttpService, enabling declarative retry logic without imperative loops.
Question 2: You need to run a NestJS background job every weekday at 9 AM UTC. Which decorator and cron expression are correct?
- @Cron('0 9 * * 1-5') on a ScheduleModule method (Correct answer)
- @Interval(9000) with a weekday guard
- @Timeout('0 9 * * 1-5') from @nestjs/schedule
- @Cron('9 * * * 1-5') on any service method
Correct answer: @Cron('0 9 * * 1-5') on a ScheduleModule method
`@Cron('0 9 * * 1-5')` means minute 0, hour 9, any day, any month, Mon-Fri — standard cron for weekday 9 AM.
Question 3: A team is building a multi-tenant SaaS app in NestJS. Each tenant's data must be isolated at the database level. What is the recommended approach using AsyncLocalStorage?
- Store the tenant ID in AsyncLocalStorage inside request-scoped middleware and inject it into a custom TypeORM connection factory (Correct answer)
- Use a global variable to track the current tenant ID
- Create a separate NestJS application instance per tenant
- Store the tenant in the JWT payload only and pass it manually to every service
Correct answer: Store the tenant ID in AsyncLocalStorage inside request-scoped middleware and inject it into a custom TypeORM connection factory
AsyncLocalStorage propagates context across async calls within a request, letting a connection factory select the correct tenant schema without threading it through every function.
Question 4: Your NestJS REST API returns 200 for both success and business errors. A code review flags this. What is the idiomatic NestJS fix?
- Throw built-in HttpExceptions (e.g., BadRequestException) and let the global exception filter map them to correct HTTP codes (Correct answer)
- Return a { success: false } object with status 200 for all errors
- Use a custom interceptor to rewrite status codes after the fact
- Set res.statusCode manually in each controller method
Correct answer: Throw built-in HttpExceptions (e.g., BadRequestException) and let the global exception filter map them to correct HTTP codes
NestJS's built-in exception layer translates HttpException subclasses to correct HTTP status codes automatically, keeping controllers clean.
Question 5: A NestJS app uses Passport JWT strategy. After deploying a new signing secret, existing valid tokens fail authentication. What went wrong?
- The new secret was not propagated to JwtModule options, so verification fails against the old secret (Correct answer)
- JWT tokens are stateful and must be re-issued from a database
- Passport caches the old secret in memory until restart
- The AuthGuard needs to be re-registered with the new module
Correct answer: The new secret was not propagated to JwtModule options, so verification fails against the old secret
JwtModule.register bakes the secret at startup; if the env variable changed without a restart, the old secret is still in use for verification.
Question 6: You want to stream large CSV files from a NestJS controller without buffering the entire file in memory. Which approach works?
- Return a Node.js Readable stream from the controller and set @Header('Content-Type','text/csv') (Correct answer)
- Use res.json() with chunked encoding enabled
- Return a Buffer wrapped in a Promise
- Use the @Sse() decorator with a CSV mime type
Correct answer: Return a Node.js Readable stream from the controller and set @Header('Content-Type','text/csv')
NestJS detects when a controller returns a Node.js stream and pipes it to the response, enabling true streaming without memory buffering.
Question 7: A NestJS CQRS app's command handler needs to publish a domain event after persisting data. Where should EventBus.publish() be called?
- After the repository save call inside the handler, before returning (Correct answer)
- In a separate scheduled job that polls the database for new records
- Inside the repository layer before the transaction commits
- In an HTTP interceptor after the response is sent
Correct answer: After the repository save call inside the handler, before returning
Publish the event after a successful save to ensure the domain event reflects persisted state; publishing before commit risks event/state inconsistency.
NestJS Case Studies & Practical Application 2
A NestJS microservice needs to handle intermittent downstream failures gracefully.
Which pattern combined with `@nestjs/axios` best implements retry logic?