What is the difference between @EventPattern() and @MessagePattern() in NestJS microservices?
@MessagePattern() handles request-response interactions where the return value is sent back to the caller. @EventPattern() handles fire-and-forget events where the return value is discarded. The client uses send() for request-response and emit() for events — both return Observables but with different semantics.
- 1
@MessagePattern — use for synchronous query-style operations where the result is needed immediately.
- 2
@EventPattern — use for domain events signaling something that happened; no response expected.
- 3
send() blocks the caller until a response is received or a timeout occurs.
- 4
emit() is non-blocking; the caller continues immediately after the message is sent.
- 5
Event-based patterns improve resilience — the emitter is decoupled from all consumers and their availability.
Scenario Questions
0-2 years experience
- 1You need to handle a simple RPC call from another service. Which decorator would you use and why?
- 2If you accidentally use @EventPattern for a request‑response interaction, what will happen at runtime?
- 3Show me how you would set up a NestJS microservice to listen for a 'user.created' event using the appropriate decorator.
2-5 years experience
- 1Your team is migrating a set of services from request‑response to an event‑driven model. How do you decide when to replace @MessagePattern with @EventPattern?
- 2During debugging you notice that a handler decorated with @EventPattern never receives messages, but a @MessagePattern handler works. What could be wrong in the transport configuration?
- 3Explain the trade‑offs of using @EventPattern for a high‑throughput stream versus @MessagePattern for occasional commands.
5-8 years experience
- 1Design a gateway that aggregates data from multiple microservices, some using @MessagePattern and others @EventPattern. How would you coordinate responses and ensure reliability?
- 2At scale you see latency spikes when many services emit events via @EventPattern on a NATS transport. What architectural changes could mitigate this?
- 3How would you implement a fallback mechanism if an @MessagePattern RPC call fails, while still processing related events via @EventPattern?
8+ years experience
- 1Your organization plans a long‑term migration from a tightly coupled RPC architecture to an event‑driven architecture across dozens of services. How would you evaluate the impact of replacing @MessagePattern with @EventPattern on contract stability, testing, and observability?
- 2When introducing a new version of an event schema, how would you handle backward compatibility for services using @EventPattern without breaking existing @MessagePattern consumers?
- 3What governance model would you propose to decide which communication pattern (event vs message) to use for new features, considering cross‑team ownership and future scalability?
Follow-up Questions
- Can you give an example where mixing the two decorators caused a bug?
- How would you test that a handler correctly distinguishes between an event and an RPC call?
- What monitoring would you add to detect misrouted messages between @EventPattern and @MessagePattern?