What is the @Payload() decorator and how do you use @Ctx() to access transport-specific context in NestJS microservices?

You need to create a NestJS microservice handler that receives a JSON payload. How would you use the @Payload() decorator to extract the data, and what would happen if you omitted it?

In a simple TCP microservice, you want to log the client’s IP address from the transport context. Show how you would use @Ctx() in the handler to get that information.

We have a message pattern that sometimes includes metadata in the transport context and sometimes doesn't. How would you safely access optional fields using @Ctx() without causing runtime errors?

During integration testing, a handler that uses @Payload() started receiving undefined values after a refactor. Walk me through how you would debug the issue and verify the decorator is applied correctly.

Our system uses RabbitMQ and gRPC transports side by side, and we need a unified way to extract correlation IDs for tracing. How would you design a utility that leverages @Ctx() to handle both transports efficiently?

When scaling the microservice, we observed that heavy payloads cause increased memory usage. Discuss trade‑offs of using @Payload() versus manually parsing the raw message inside the handler.

We are migrating a legacy monolith to a NestJS microservice architecture and need to preserve existing request context (auth tokens, request IDs) across multiple transports. How would you architect the use of @Ctx() and possibly custom decorators to ensure consistent context propagation across teams?

Consider a cross‑team initiative to implement end‑to‑end tracing across all NestJS microservices. What are the implications of relying on @Ctx() for transport‑specific data, and how would you standardize context handling to avoid duplication and maintainability issues?