class-validator supports groups — decorators declare which groups they belong to, and ValidationPipe is configured with a specific group to run. Extend ValidationPipe with different group settings for create (all fields required) and update (all fields optional) handlers.

Validation groups for create and update DTOs

Validation group patterns:

1
Decorators without a groups option apply to ALL groups — always specify groups explicitly.
2
Use skipMissingProperties: true on update groups so absent fields are not treated as errors.
3
Groups are passed as a string array — multiple groups can be active simultaneously.
4
A decorator with groups: ['create'] is completely ignored during update validation.
5
For simple create/update patterns, separate CreateDto and UpdateDto classes (with PartialType) is often cleaner.

Difficulty: 5/10

Topics: validation groups, DTOs, NestJS pipes

Scenario Questions

0-2 years experience

1
We have a CreateUserDto and an UpdateUserDto. How would you set up class-validator so that the email field is required on create but optional on update using validation groups?
2
If you forget to pass a validation group to the ValidationPipe, what will happen to the rules you defined for the 'update' group?
3
Show me how you would annotate a password field to be required only for the 'register' group.

2-5 years experience

1
During a sprint we added an 'isAdmin' flag to the User DTO, but updates are now failing validation. Walk me through how you'd debug the issue with validation groups.
2
We need to support partial PATCH requests without over‑validating fields. Explain why you might choose validation groups over the pipe's 'skipMissingProperties' option, and how you'd implement it.
3
Our API uses a global ValidationPipe with whitelist:true. How does that interact with group‑specific constraints, and what would you change if a client reports a field is being stripped on update?

5-8 years experience

1
In a microservice architecture, several services share the same DTO definitions but have different validation requirements for create vs sync operations. How would you design a shared validation group strategy to avoid duplication and keep compile‑time safety?
2
Consider a high‑traffic endpoint that validates large payloads with multiple groups. What are the performance implications of using class-validator's groups, and how would you mitigate any overhead?
3
If you need to version your API (v1 vs v2) and the validation rules differ, how would you extend the validation group concept to handle version‑specific constraints while keeping the codebase maintainable?

8+ years experience

1
Our organization is moving from NestJS to a polyglot stack, but we want a consistent validation contract across services in different languages. How would you evolve the use of class-validator groups to a language‑agnostic schema, and what migration path would you propose?
2
Several product teams have added custom decorators that rely on validation groups, leading to conflicting group names. As a staff engineer, how would you establish a governance model for validation groups to prevent such collisions in a large codebase?
3
Discuss the pros and cons of keeping validation logic in the NestJS layer (using class-validator) versus moving it to a GraphQL schema or OpenAPI spec, especially when groups differentiate create/update. What would you recommend for a company scaling to dozens of microservices?

Follow-up Questions

❓What happens if a request doesn't specify any validation group?
❓Can you apply multiple groups at once, and why would you do that?
❓How does the global ValidationPipe interact with per‑route group settings?