NestJS Case Studies & Practical Application 4 — Questions and Answers
Question 1: A NestJS app needs feature flags that can be toggled without redeployment. Which design best achieves this?
- Store flags in a Redis/database store, inject a FeatureFlagService, and guard feature branches with it (Correct answer)
- Use environment variables baked into the Docker image at build time
- Use TypeScript conditional compilation with @ifdef comments
- Hard-code boolean flags in a config file committed to the repo
Correct answer: Store flags in a Redis/database store, inject a FeatureFlagService, and guard feature branches with it
A database or cache-backed FeatureFlagService allows runtime toggling without redeployment, while remaining injectable across the NestJS DI graph.
Question 2: Your NestJS service must call three independent external APIs and aggregate results. What is the most efficient approach?
- Use Promise.all([apiA(), apiB(), apiC()]) to call them concurrently (Correct answer)
- Call them sequentially with await to avoid race conditions
- Use setImmediate to stagger the calls
- Use a queue to serialize each request for reliability
Correct answer: Use Promise.all([apiA(), apiB(), apiC()]) to call them concurrently
Promise.all fires all three requests simultaneously, reducing total latency to the slowest individual call rather than the sum of all three.
Question 3: A NestJS unit test for a service that depends on a repository always hits the real database. What is wrong?
- The test module imports TypeOrmModule.forRoot() instead of mocking the repository with { provide: getRepositoryToken(Entity), useValue: mockRepo } (Correct answer)
- The test file imports the wrong test runner
- TypeORM cannot be mocked in NestJS unit tests
- The @InjectRepository decorator prevents mock injection
Correct answer: The test module imports TypeOrmModule.forRoot() instead of mocking the repository with { provide: getRepositoryToken(Entity), useValue: mockRepo }
Providing a mock via getRepositoryToken(Entity) replaces the real repository in the DI container, ensuring the service never touches a database.
Question 4: A NestJS app is deployed on Kubernetes with 5 replicas. Session data stored in memory on each instance causes inconsistent behavior. What is the fix?
- Move session storage to a shared Redis cluster using connect-redis with the NestJS session middleware (Correct answer)
- Increase pod memory limits to reduce evictions
- Use sticky sessions via the Kubernetes ingress controller
- Store sessions in a local SQLite file on each pod
Correct answer: Move session storage to a shared Redis cluster using connect-redis with the NestJS session middleware
A shared Redis store makes session data consistent across all replicas; sticky sessions are a workaround that fails when pods restart.
Question 5: You need to add OpenTelemetry tracing to a NestJS app so every HTTP request gets a trace ID propagated to downstream services. Which integration point is correct?
- Initialize the OTEL SDK before NestFactory.create() in main.ts and use the @opentelemetry/instrumentation-http package (Correct answer)
- Add a custom decorator to every controller method
- Use APP_INTERCEPTOR to manually generate UUIDs per request
- Configure tracing inside a TypeORM subscriber for database calls only
Correct answer: Initialize the OTEL SDK before NestFactory.create() in main.ts and use the @opentelemetry/instrumentation-http package
The OTEL SDK must initialize before any modules load so auto-instrumentation can patch Node.js's http module and establish context propagation from the start.
Question 6: A NestJS API gateway aggregates responses from three downstream microservices. One service is slow, degrading all requests. Which pattern isolates the slow service?
- Apply a Circuit Breaker (e.g., via cockatiel or opossum) around the slow service's client calls (Correct answer)
- Increase the HTTP timeout to give it more time
- Move the slow service call to a background job
- Cache the slow service response forever using Redis
Correct answer: Apply a Circuit Breaker (e.g., via cockatiel or opossum) around the slow service's client calls
A Circuit Breaker detects repeated failures/timeouts and short-circuits calls to the failing service, returning a fallback without waiting for the full timeout.
Question 7: A NestJS app's ConfigModule loads .env files. In production, secrets should come from AWS Secrets Manager, not files. What is the cleanest approach?
- Use ConfigModule.forRootAsync() with a custom factory that fetches secrets from the AWS SDK and merges them with default config (Correct answer)
- Store AWS secrets in the .env file checked into the repo
- Create a separate NestJS bootstrap module that sets process.env before startup
- Use a pre-start shell script to export secrets as env vars
Correct answer: Use ConfigModule.forRootAsync() with a custom factory that fetches secrets from the AWS SDK and merges them with default config
forRootAsync allows an async factory with injected dependencies, making it the idiomatic NestJS way to load secrets from external sources at startup.
NestJS Case Studies & Practical Application 4
A NestJS app needs feature flags that can be toggled without redeployment.
Which design best achieves this?