NestJS in production

6 questions drawn from the parts of this series. Answers here count toward each post's own quiz.

1. Question 1 of 6·IntermediateIn the chain OrdersController → OrdersService → OrderRepository → TenantContext, only TenantContext is REQUEST scoped. What happens to the other providers?

   They stay singletons, because scope only applies to the provider declared as REQUESTThey stay singletons, but Nest injects a fresh TenantContext into them on every requestThey also become REQUEST scoped, so the whole branch is rebuilt on every requestNest throws at boot because a singleton may not depend on a REQUEST-scoped provider
2. Question 2 of 6·IntermediateTwo feature modules, orders and payments, import each other through forwardRef. Which fix matches the post's approach?

   Keep forwardRef but make sure the modules initialise in the order you expectFind the real dependency direction: synchronous commands go one way through a port, the reverse direction uses domain eventsMark payments as @Global() so that orders no longer needs to import itMove the providers involved to REQUEST scope so the cycle is resolved at runtime
3. Question 3 of 6·IntermediateWhy is await orders.save(order); await queue.add('capture-payment', ...) unsafe, and how does an outbox address the root cause?

   Because queue.add() is slow; an outbox gets jobs into the queue faster by batchingBecause the two stores share no transaction, so a crash between the lines silently loses the job; an outbox writes the intent to the same database in the same transaction as the orderBecause Redis is not durable; an outbox replaces Redis with Postgres as the job runnerBecause the job might run twice; an outbox guarantees each job is delivered exactly once
4. Question 4 of 6·StarterBullMQ delivers jobs at-least-once. What realistic goal does the post propose for jobs with consequences?

   Configure the queue to achieve exactly-once delivery across the networkSwitch every job to at-most-once so a customer is never charged twiceExactly-once effect: deliver at least once and write handlers so a second run causes no extra consequenceDisable retries so each job can only ever run once
5. Question 5 of 6·IntermediateYour team uses 7-day JWT access tokens because they are "stateless and fast". Product then asks to "lock a hijacked account immediately". What is most accurate?

   JWT is still stateless: changing the user's password automatically invalidates every old token.Revoking before exp requires adding state (a denylist, tokenVersion, a Redis check), so keep access tokens short and put revocation in the refresh token.Deleting the token on the client when the user clicks logout is enough to make that token unusable.Shortening exp to a few seconds is the only option, accepting that every request needs a fresh login.
6. Question 6 of 6·AdvancedWith refresh token rotation, an already-used refresh token shows up at the server again. Why should the server revoke the whole family instead of just rejecting that request?

   Because the old token was surely sent by the attacker, so only that attacker's session needs to be punished.Because revoking the whole family frees up memory in the store faster.Because the server cannot tell the real user from a thief when both hold a copy; a replayed token is evidence of a copy, so revoking everything is the safe move.Because the family's 60-day absolute lifetime has expired and a new login is required.