Create an HTTP-facing NestJS application that injects multiple ClientProxy instances — one per downstream service. Use sequential calls when each step depends on the previous result. Use Promise.all() for independent parallel calls. Map RpcException errors to appropriate HTTP exceptions using catchError() in the pipeline.
Use Promise.all() for independent downstream calls — runs them in parallel and halves latency.
Use sequential awaits only when each call depends on the result of the previous one.
Apply a global RpcExceptionFilter to convert microservice errors to HTTP responses on the gateway.
Add timeout operators (timeout(3000)) to prevent a slow service from hanging the gateway response.
The gateway should be thin — business logic belongs in the downstream services, not the gateway.
You need to expose a single endpoint that calls two internal NestJS microservices and returns a combined response. How would you set up the gateway controller and service to achieve this?
If one of the downstream services times out, what would the gateway return and how would you handle it in NestJS?
Describe the steps to register a microservice client in the gateway module.
We have a new feature where the gateway must aggregate data from three microservices, each with different response formats. How would you design the transformation layer, and what trade‑offs would you consider?
During testing the gateway started returning 502 errors when the user service is under load. Walk me through how you would debug the issue in NestJS.
Explain why you might choose HTTP vs. TCP transport for the microservice clients in the gateway, and how that choice impacts latency and reliability.
Our platform expects the gateway to handle 10k requests per second and aggregate data from five services. What architectural changes would you make in NestJS to ensure scalability and low latency?
How would you implement circuit breaking and fallback responses in a NestJS API Gateway that aggregates multiple services?
Discuss how you would handle versioning of downstream microservice APIs in the gateway without redeploying the entire gateway.
We are consolidating several legacy microservices into a new NestJS API Gateway. How would you plan the migration to minimize downtime and ensure backward compatibility across teams?
At a company‑wide level, what governance and observability strategies would you put in place for a NestJS API Gateway that serves as the entry point for dozens of services?
If the organization decides to move from a monolithic gateway to a distributed edge‑proxy model, how would you redesign the NestJS gateway architecture and what impact would it have on cross‑team responsibilities?