What is the difference between a shared module and a global module in NestJS?
A shared module exports providers so other modules can import it explicitly. A global module (decorated with @Global()) registers its exported providers application-wide so no explicit import is needed. Global modules should be registered only once in the root module and used sparingly to avoid hidden coupling.
A shared module is the standard pattern — it exports providers and must be imported explicitly by any module that wants to use them. A global module uses @Global() so its exports are available everywhere without needing to be imported.
- 1
Shared module — default choice; explicit imports keep dependencies traceable.
- 2
Global module — use only for truly cross-cutting infrastructure like logging, config, or database connections.
- 3
Global modules should be registered only once, in the root AppModule.
- 4
Overusing @Global() leads to hidden coupling and makes modules harder to test in isolation.
Scenario Questions
0-2 years experience
- 1You need to reuse a LoggerService across two feature modules. How would you set it up using a shared module, and what would you have to do differently if you made the LoggerModule global?
- 2If you forget to add a provider to the exports array of a shared module, what runtime error would you see when another module tries to inject it?
- 3What happens when you import a module marked with @Global() into the root AppModule versus importing it into a feature module?
2-5 years experience
- 1During a sprint, a teammate added a new service to a shared module but didn't export it, causing a dependent module to fail. Walk me through how you'd debug and fix it.
- 2We have a configuration service needed only in a few modules. Would you choose a global module or a shared module for this, and why?
- 3Our application started throwing 'Nest cannot resolve dependencies' after we turned a shared module into a global one. What could be the cause?
5-8 years experience
- 1With dozens of feature modules, discuss the performance and maintainability implications of marking many modules as global versus keeping them shared.
- 2How would you design a plugin system where third‑party modules can register providers without polluting the global namespace? Relate this to shared vs global modules.
- 3If you need to lazy‑load a module that provides a heavy database connection, why might a shared module be preferable to a global module, and how would you implement it?
8+ years experience
- 1Our monorepo contains multiple NestJS microservices that share common utilities. Describe a strategy for managing shared code that avoids overusing global modules while keeping versioning and deployment simple.
- 2When migrating a legacy NestJS codebase that heavily relies on @Global() modules, what steps would you take to refactor toward shared modules to improve testability and isolation?
- 3Consider a scenario where a global module registers a provider that holds mutable state. What architectural risks does this introduce across teams, and how would you mitigate them?
Follow-up Questions
- What are the main downsides of using a global module in a large codebase?
- How does NestJS resolve provider scope when a provider is declared in both a shared and a global module?
- Can you describe a situation where a global module caused a circular dependency and how you would break it?