When to Choose RPC vs MQ: Decoupling Strategies for Reliable Services

Many claim that message queues (MQ) are the ultimate tool for decoupling architectures and that RPC should be avoided whenever possible. The article examines whether this view holds true and clarifies the appropriate scenarios for each communication method.

When to Use RPC?

Use RPC when the caller must know the execution result. For example, a login page calls a passport service and must handle success, failure, or error based on the service’s return value.

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

In such cases, the caller cares about the outcome, so RPC is the natural choice.

Why Not Force MQ for Decoupling?

Attempting to replace RPC with MQ for the same flow makes the caller wait for an asynchronous message, complicating code and introducing the risk of message loss. Adding an extra MQ layer merely to achieve decoupling is rarely practical.

Can RPC Be Used Everywhere?

No. If the caller does not need the execution result, using RPC creates tight coupling and potential bottlenecks. The article illustrates this with a generic upstream service (e.g., a “post publishing” service) that many downstream business units care about only the event, not its processing outcome.

Downstream concerns include:

Big‑data teams updating user profiles after a post is published.

Content‑quality teams asynchronously checking post compliance.

Recruitment teams awarding points for job‑related posts.

If the upstream service notifies downstreams via RPC, any change in downstream requirements forces the upstream to modify its code, leading to painful coupling and maintenance overhead.

How to Decouple Effectively?

When the event source does not need to know downstream results, MQ should be used. MQ provides both physical and logical decoupling:

Physical decoupling: Upstream services connect only to the MQ broker, not directly to each downstream, eliminating direct network dependencies.

Logical decoupling: The publisher does not need to know which consumers subscribe; new consumers simply connect to the MQ.

Key Takeaways

1. Use RPC when you need to know the downstream execution result.

2. Use MQ when you do not need the result, avoiding RPC and achieving clean decoupling.

These guidelines, though simple, significantly improve service isolation and scalability.

Understanding the reasoning behind each choice is more valuable than memorizing the conclusion.