forRoot() registers global configuration once. forFeature() registers feature-specific providers that depend on the global config — similar to how TypeORM works with entities. forFeature() relies on providers from forRoot() being already registered globally, so it can inject them via the DI container.

forRoot() and forFeature() working together

forRoot vs forFeature responsibilities:

1
forRoot — registers infrastructure once globally: connections, global config, shared clients.
2
forFeature — registers per-module resources: entity repositories, feature-scoped services.
3
forFeature providers can inject forRoot providers because global providers are available app-wide.
4
This pattern is used by TypeOrmModule, MongooseModule, and SequelizeModule in the NestJS ecosystem.

Difficulty: 6/10

Topics: Dynamic modules, forRoot/forFeature pattern, module registration

Scenario Questions

0-2 years experience

1
You need to add a new repository to an existing NestJS module that already uses forRoot(). How would you expose it using a forFeature() method?
2
If you import a feature module that calls forFeature() twice with different providers, what will the injected service resolve to?
3
What do you need to import in a feature module to get access to a service that was registered via the core module's forRoot()?

2-5 years experience

1
Your team added a new feature module that calls forFeature(), but the injected service is undefined at runtime. Walk me through how you'd debug the issue.
2
Explain the trade‑offs of placing a shared provider in forRoot() versus in each module's forFeature() when you have several feature modules.
3
If a feature module also needs its own configuration in addition to the global config from forRoot(), how would you design the API?

5-8 years experience

1
Design a dynamic module that supports global configuration via forRoot() and per‑feature overrides via forFeature(). What edge cases must you guard against?
2
How would you ensure that providers registered through forFeature() are correctly scoped and don’t cause memory leaks in a high‑traffic NestJS service?
3
Discuss the performance implications of loading many feature modules with forFeature() at startup versus lazy‑loading them.

8+ years experience

1
Your organization is migrating a monolithic NestJS app to microservices. How would you refactor existing forRoot/forFeature modules to support independent deployment while preserving shared configuration?
2
What versioning or governance strategy would you put in place for a shared library that exposes both forRoot() and forFeature() to avoid breaking changes across multiple teams?
3
Multiple teams need to extend a core module with custom providers via forFeature(). How would you design the module’s API and documentation to ensure consistency and prevent circular dependencies?

Follow-up Questions

❓What would happen if you forgot to export the providers from the forFeature() call?
❓How does NestJS determine the scope of a provider registered via forFeature() versus forRoot()?
❓Can you describe a situation where two feature modules might conflict because of shared provider tokens?