Questions
8 of 25
1What are dynamic modules in NestJS and when do you use them?
2How would you lazy-load a module in NestJS to improve startup time?
3What are the four properties inside @Module() decorator?
4What is the difference between a shared module and a global module in NestJS?
5What is a NestJS module, and why is it needed?
6What is the difference between exports in a module and making a provider global with @Global()?
7What is the purpose of a module in NestJS and what does the @Module() decorator do?
8Are NestJS modules singletons? What does that mean practically?
9What is a feature module in NestJS and why should you use them instead of putting everything in AppModule?
10Can a feature module re-export an imported module in NestJS? When is this useful?
11What does the @Global() decorator do and how does it change module behaviour in NestJS?
12What are the risks of overusing @Global() modules in NestJS?
13How do you register a global module exactly once in NestJS and what happens if you register it twice?
14What is the naming convention for dynamic module static methods in NestJS and what does each name signal?
15How do you structure a feature module that has sub-features in NestJS?
16What is the difference between a shared module and a global module in NestJS?
17How can a dynamic module expose a forFeature() method that works alongside a forRoot() registration in NestJS?
18What is the module encapsulation rule in NestJS and why does it matter?
19What must the object returned by a dynamic module's static method always include in NestJS?
20What is the difference between imports and providers inside @Module()?
21What is a shared module in NestJS?
22When should you export a module vs export individual providers from a module in NestJS?
23What is a dynamic module in NestJS and how is it different from a static module?
24How do you implement forRootAsync() in a dynamic module so that options can be loaded asynchronously from ConfigService?
25How do you write a dynamic module that supports both sync (register) and async (registerAsync) configuration sharing the same internal providers?
08 / 25

Are NestJS modules singletons? What does that mean practically?

Difficulty: 5/10
module lifecycle, dependency injection, provider scope

Yes — every module is instantiated exactly once by the NestJS runtime regardless of how many other modules import it. All providers within the module share the same singleton instances across all consumers. The module graph is built once at bootstrap and cached for the application lifetime.

Module singletons mean you never worry about duplicate instantiation when sharing modules across features. If two modules both import UsersModule, there is still only one UsersModule instance and one UsersService instance.

Module singleton behavior
Practical implications:
  1. 1

    Shared state in a singleton service is shared across all consumers — design services to be stateless.

  2. 2

    No need to worry about redundant instantiation when the same module is imported in multiple places.

  3. 3

    The module graph is built once at startup — there is no runtime module registration after bootstrap.

  4. 4

    Provider instances are reused across the application lifetime unless scope is changed to REQUEST or TRANSIENT.

Scenario Questions

0-2 years experience

  1. 1If you create two services inside the same NestJS module and inject them into two different controllers, will they share the same instance? Explain what happens.
  2. 2How would you register a provider so that each request gets a new instance instead of the default singleton?
  3. 3What would happen if you accidentally add the same provider to two different modules?

2-5 years experience

  1. 1You notice that a stateful service is leaking data between requests. Walk me through how you would debug this in NestJS and what module singleton behavior might be causing it.
  2. 2Suppose you need two different implementations of a logging service in different parts of the app. How would you configure modules to avoid the singleton conflict?
  3. 3Why might moving a provider from a global module to a feature module fix a bug you’re seeing?

5-8 years experience

  1. 1Design a multi‑tenant NestJS application where each tenant should have its own instance of a configuration service. How would you handle the singleton nature of modules to achieve isolation?
  2. 2Discuss the performance implications of having many globally‑scoped singleton providers versus lazy‑loaded feature modules.
  3. 3If you need to hot‑reload a module in production without restarting the server, how does the singleton nature affect your approach?

8+ years experience

  1. 1Your organization is migrating a monolithic NestJS codebase to a microservices architecture. How would you refactor module boundaries and singleton providers to minimize coupling and support independent deployment?
  2. 2When multiple teams share a common library of NestJS modules, what governance practices would you put in place to manage singleton state and avoid hidden side effects?
  3. 3Consider a scenario where a globally‑scoped provider holds a cache that grows unbounded. How would you redesign the module/provider structure to mitigate memory risks while preserving performance?

Follow-up Questions

  • What problems can arise from that shared state?
  • How would you change the scope if you needed per‑request instances?
  • Can you give an example where a global module caused an unexpected bug?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.