How do you handle errors in microservice request-response patterns and propagate them to the caller in NestJS?
Throw RpcException on the microservice side to send structured errors back to the caller. On the API gateway or caller side, catch errors in the Observable pipeline with catchError() and rethrow as HTTP exceptions. Register a global RpcExceptionFilter to convert RpcException to HTTP responses on the gateway.
- 1
RpcException is the correct exception class for microservice handlers — plain Error objects are not serialized properly.
- 2
Pass an object to RpcException with statusCode and message for structured error payloads.
- 3
The gateway must have a global RpcExceptionFilter to convert RpcException to HTTP responses.
- 4
catchError() in the Observable pipeline intercepts errors from send() before they propagate as unhandled.
- 5
throwError(() => new HttpException(...)) re-throws as an HTTP exception so the gateway's exception filters handle it.
Scenario Questions
0-2 years experience
- 1You need to call another NestJS microservice via TCP and return the result to an HTTP client. How would you catch an error from the remote service and send an appropriate HTTP status code back?
- 2If a service method throws a custom HttpException, what will the NestJS framework do when the request originates from a microservice client, and how can you ensure the caller receives the same error details?
- 3Describe the steps to add a global exception filter that transforms all microservice errors into a standard JSON payload.
2-5 years experience
- 1During a recent feature you added a fallback when a downstream payment microservice is unavailable. The fallback isn’t being triggered even though the remote call times out. Walk me through how you’d debug the error propagation in NestJS.
- 2You need to propagate validation errors from a user‑service microservice back to the original HTTP gateway, preserving the original error code and message. What trade‑offs exist between using HttpException vs. custom error objects, and how would you implement it?
- 3Explain how you would configure a NestJS microservice client to retry on transient errors and still surface the final failure to the caller.
5-8 years experience
- 1At scale, you notice that error payloads from several microservices are inflating response sizes and causing latency. How would you redesign error handling and propagation in NestJS to mitigate this while keeping enough diagnostic info?
- 2Your system uses both gRPC and RabbitMQ transports. How do you ensure a consistent error contract across these transports, and what changes would you make to the exception filters or interceptors?
- 3If a downstream service crashes and the NestJS gateway keeps retrying, how would you prevent cascading failures and still surface a meaningful error to the original client?
8+ years experience
- 1The organization is moving from a monolith to a NestJS microservice architecture. What long‑term strategy would you propose for standardizing error handling and propagation across dozens of services, considering versioning, observability, and backward compatibility?
- 2Multiple teams have built their own custom exception filters. How would you consolidate them into a unified approach without breaking existing contracts, and what governance process would you put in place?
- 3Discuss the implications of propagating stack traces to external callers in a public API. How would you design the error handling layer to balance security, debuggability, and compliance across all NestJS services?
Follow-up Questions
- What changes would you make if you needed to hide internal error codes from external clients?
- How does NestJS differentiate between HTTP and microservice contexts when handling exceptions?
- Can you show a minimal example of the JSON error shape you would return?