Patterns inside NestJS: a practical guide for developers

After spending months building production services with NestJS, I've realized that the framework isn't just a collection of decorators—it's a masterclass in design patterns baked into every layer. Understanding Patterns inside NestJS transforms you from someone who copies tutorials into someone who designs systems that scale. In this article, I'll walk you through the core architectural patterns that make NestJS powerful, and how recognizing them will make you a faster, more confident developer.

Modules and DI: Inversion of Control

The module system is where NestJS establishes its spine. Every feature you build sits inside a module, and modules explicitly declare what they provide and what they depend on. This is pure Inversion of Control (IoC)—you're not manually instantiating services; the framework decides when and how to create them.

When I built a ride-hailing platform, we had user management, payments, and notifications tightly coupled in a monolith. Moving to NestJS forced us to think in modules. The UserModule provides a UserService, the PaymentModule imports it, and the framework wires everything together. You declare dependencies as constructor parameters, and NestJS resolves the dependency graph automatically.

@Injectable()
export class UserService {
  constructor(private db: DatabaseService) {}
  
  async findById(id: string) {
    return this.db.query('SELECT * FROM users WHERE id = ?', [id]);
  }
}

@Module({
  providers: [UserService, DatabaseService],
  exports: [UserService],
})
export class UserModule {}

The real power surfaces when you need to swap implementations. In testing, inject a mock DatabaseService. In staging, swap it for a different database driver. The UserService never changes—it depends on an abstraction, not a concrete implementation. This is the Dependency Injection container at work, and it's why NestJS services remain testable and flexible across environments.

Guards and Interceptors: Chain of Responsibility and Decorator

Request handling in NestJS follows the Chain of Responsibility pattern. A request flows through guards, then interceptors (before), then your controller, then interceptors (after), then filters catch errors. Each layer can stop the chain or pass it forward.

On a SaaS billing platform, we needed role-based access control, request logging, and response transformation. Guards handle authorization (check if the user is an admin). Interceptors wrap the entire request-response cycle. This separation of concerns meant we could add, remove, or modify cross-cutting logic without touching business logic.

@Injectable()
export class AdminGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    return request.user?.role === 'admin';
  }
}

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler) {
    console.log(`Incoming: ${context.switchToHttp().getRequest().method}`);
    return next.handle().pipe(
      tap(() => console.log('Request completed'))
    );
  }
}

@Controller('/admin')
@UseGuards(AdminGuard)
@UseInterceptors(LoggingInterceptor)
export class AdminController {
  @Post('users')
  createUser(@Body() dto: CreateUserDto) {
    // Only admins reach here
  }
}

Guards implement the Decorator pattern too—you stack them with @UseGuards(Guard1, Guard2), and each one wraps the next, creating a pipeline. This is why you can compose authentication, rate limiting, and custom validation rules without nested if-statements in your controller.

Pipes: Strategy for Validation

Pipes are the Strategy pattern in action. They transform or validate data before it hits your handler. Different pipes apply different strategies: one might validate schema, another might parse JSON, another might convert types.

On a travel booking system, we had multiple DTOs across different endpoints. Instead of scattering validation logic everywhere, we created pipes: ValidationPipe for schema validation, ParseIntPipe for converting query params, CustomAuthPipe for extracting and verifying JWT claims. Each pipe knows one strategy; you compose them by declaring which pipe to use on which parameter.

@Injectable()
export class CustomValidationPipe implements PipeTransform {
  transform(value: any, metadata: ArgumentMetadata) {
    if (!value.email.includes('@')) {
      throw new BadRequestException('Invalid email');
    }
    return value;
  }
}

@Controller('/bookings')
export class BookingController {
  @Post()
  createBooking(
    @Body(new CustomValidationPipe()) dto: CreateBookingDto,
  ) {
    return this.bookingService.create(dto);
  }

  @Get(':id')
  getBooking(@Param('id', ParseIntPipe) id: number) {
    return this.bookingService.findById(id);
  }
}

The beauty: you can reuse pipes across controllers, test them in isolation, and swap strategies without changing handler signatures. In our e-commerce platform, we built a TrimStringsPipe to sanitize input and a TransformPipe to convert nested DTOs—both applied globally through app.useGlobalPipes(). When we later needed stricter validation for sensitive fields, we created a new pipe and applied it only where needed.

Dynamic Modules: Factory

The Factory pattern appears in NestJS's dynamic module system. Static modules are hardcoded; dynamic modules generate their configuration at runtime based on parameters you pass.

When we built a multi-tenant CRM, each tenant needed separate database credentials, feature flags, and API keys. A static module wouldn't work. We created a dynamic TenantModule that used a factory to generate providers on-the-fly based on tenant configuration.

export class TenantService {
  constructor(
    @Inject('TENANT_CONFIG') private config: TenantConfig,
    private db: DatabaseService,
  ) {}

  async getConnection() {
    return this.db.connect(this.config.connectionString);
  }
}

export class TenantModule {
  static register(config: TenantConfig): DynamicModule {
    return {
      module: TenantModule,
      providers: [
        {
          provide: 'TENANT_CONFIG',
          useValue: config,
        },
        TenantService,
      ],
      exports: [TenantService],
    };
  }
}

// Usage in app.module.ts
@Module({
  imports: [
    TenantModule.register({
      tenantId: 'acme-corp',
      connectionString: process.env.TENANT_DB_URL,
    }),
  ],
})
export class AppModule {}

This pattern scales beautifully. In microservices, we used ConfigModule.register() to pass different Kafka brokers, Redis URLs, and feature flags to each service instance. The factory generates the exact module configuration needed without duplicating code across environments.

Common Mistakes

I've seen mid-level developers miss these patterns and pay the price:

• Bypassing DI: Directly importing and instantiating services breaks the IoC container. I once saw someone do const service = new MyService() in a controller—it made testing impossible. Always inject through the constructor.
• Guard vs. Interceptor confusion: Guards determine if a request proceeds; interceptors wrap the response. I've watched developers use guards for logging (wrong; use interceptors) and interceptors for authentication (wrong; use guards). Know the order and purpose of each.
• Validation logic in controllers: Pipes exist for transformation and validation. Putting it in the handler makes pipes pointless. I refactored a codebase where 30% of controller code was manual validation—five custom pipes replaced it all.
• Static modules everywhere: Not every module needs to be dynamic, but overusing static modules kills flexibility. In our trading platform, we initially hardcoded exchange URLs in modules; switching to dynamic modules made staging and production configurations trivial.

Key Takeaways

• NestJS embeds design patterns into its architecture—recognizing them makes you understand the framework faster and design better systems.
• Modules and Dependency Injection establish Inversion of Control, keeping your code testable and environment-agnostic.
• Guards and Interceptors implement Chain of Responsibility and Decorator patterns, letting you layer cross-cutting concerns without tangling business logic.
• Pipes apply the Strategy pattern for validation and transformation, making it easy to reuse and compose data-handling logic across endpoints.
• Dynamic Modules use the Factory pattern to generate configuration at runtime, enabling multi-tenancy, microservices, and environment-specific setups.
• Understanding these patterns helps you write code that's easier to test, scale, and maintain across production platforms.