A module is a class decorated with @Module() that acts as the organizational unit of a NestJS app. It groups related controllers, providers, and imports. Every app has at least one root module (AppModule). NestJS uses the module graph to wire up the DI container at startup.

A module is a class annotated with the @Module() decorator. NestJS uses the information provided by this decorator to organize the application structure and build the dependency injection container.

Key points about modules:

1
Every NestJS app has at least one root module — AppModule.
2
Modules encapsulate a closely related set of capabilities.
3
The module graph is used by NestJS to resolve provider dependencies.
4
Modules are singletons by default — the same instance is shared across the app.

Basic module example

Difficulty: 5/10

Topics: module organization, dependency injection, scoping

Scenario Questions

0-2 years experience

1
If you need to add a new service for sending emails, how would you structure a NestJS module for it, and what steps are required to make the service available to other parts of the app?
2
What happens if you forget to import a module that provides a controller you want to use in another module?
3
Where would you place shared utility functions and how would you expose them through a module?

2-5 years experience

1
We have a UsersModule and an AuthModule, but Auth needs the UsersService. How would you resolve this circular dependency using NestJS modules?
2
After moving some providers into a new module, a previously working endpoint started returning 500 errors. Walk me through how you would debug the issue and what module‑related pitfalls you’d check.
3
If you need to load a module only in a testing environment, what approaches does NestJS provide and what are the trade‑offs?

5-8 years experience

1
Our monolith is growing and we plan to split it into several bounded‑context modules that will be loaded lazily. How would you design the module hierarchy to minimize startup time and keep DI performant?
2
How would you share a cache service across multiple dynamically loaded modules without creating duplicate instances, and which module configuration patterns would you use?
3
When integrating a third‑party library that requires global configuration, how would you decide between a global module and a scoped module, considering testability and future scaling?

8+ years experience

1
We are migrating a legacy Express codebase to NestJS. How would you reorganize the existing code into NestJS modules to ensure clean separation of concerns while allowing incremental migration?
2
Several teams need a common authentication module that must evolve independently. What architectural strategies would you employ to version and share this module without causing breaking changes for downstream services?
3
If the company mandates that all modules expose only explicit public providers and avoid accidental leaks, how would you enforce this at the framework or CI level?

Follow-up Questions

❓How would you make a provider available across the entire application without importing its module everywhere?
❓What are the trade‑offs of using the @Global() decorator on a module?
❓Can you describe a strategy to test that a module correctly exports its intended providers?