When Should You Choose RPC Over MQ? A Practical Guide to Decoupling Services

Many people claim that a message queue (MQ) is the ultimate tool for architectural decoupling and that RPC should be avoided whenever possible. This article examines whether that view is correct and clarifies the scenarios where RPC is appropriate.

When to Use RPC

If the caller cares about the execution result, RPC is the natural choice. For example, a login page calls a PassportService::userAuth(name, pass) method and then switches on the return value to render different HTML responses:

ret = PassportService::userAuth(name, pass);
switch(ret){
  case(YES) : return YesHTML();
  case(NO) : return NoHTML();
  case(JUMP) : return 304HTML();
  default : return 500HTML();
}

When the caller needs to know whether the login succeeded, failed, or encountered an error, RPC provides the synchronous feedback required.

Why Not Force MQ for All Decoupling?

Using MQ for a request‑response flow forces the caller to wait for a callback, complicating the code and introducing the risk of message loss. Adding an extra asynchronous layer merely to simulate a synchronous response is rarely practical.

When Not to Use RPC

If the caller does not care about the downstream execution result, using RPC creates tight coupling and bottlenecks. For instance, a generic "post publishing" service may need to notify multiple downstream systems (analytics, compliance, recruitment scoring, etc.). Making the upstream service invoke each downstream via RPC would mean that any new downstream requirement forces a code change in the upstream service, leading to ownership frustration and stability issues.

How to Decouple Effectively

When the event producer does not need to know the consumer's execution result, MQ should be used instead of RPC. MQ achieves decoupling both physically and logically:

Physical decoupling: After introducing MQ, upstream services no longer maintain direct connections to downstream services; they only connect to the MQ broker.

Logical decoupling: The producer does not need to know which consumers have subscribed to the message. Adding a new consumer only requires connecting to the MQ, without any changes to the producer.

Key Takeaways

1. Use RPC when the caller must know the downstream execution result.

2. Use MQ when the caller does not need the result, allowing both physical and logical decoupling.

Although this is a small optimization, it dramatically improves notification decoupling and overall system robustness.