Don’t Mix Them Up: When to Use RPC, MQ, or Offline Scripts

Three Core Mechanisms

Experienced architects often find that complex business systems can be reduced to three fundamental processing models:

Synchronous RPC – Immediate result needed, low latency.

Asynchronous MQ – Accepts messages first, processes them later, high throughput.

Offline scripts – Runs at night, focuses on compute power.

These three are frequently confused, leading to poor design choices and painful post‑deployment issues.

Decision Matrix (summary of the original table)

Key dimensions include what the caller wants, statefulness, lifecycle, I/O model, bottlenecks, and primary metrics.

Web/API calls : need low latency, stateless, use NIO/Reactor, monitor RT/QPS/error rate.

Message‑queue middleware : need high throughput, strong state, use zero‑copy + sequential disk writes, monitor lag and disk I/O.

CLI/offline jobs : need raw compute, essentially stateless, use streaming/MMAP, monitor task progress, exit code, resource usage.

Lifecycle Comparison

Web Applications

Stateless workers that handle a request and exit. If a node fails, the load balancer routes traffic elsewhere, keeping user experience smooth.

Message Queues

Strongly stateful; a Kafka partition is bound to a disk on a specific machine, creating "topology stickiness". Rebalancing or Raft‑based logs (e.g., RocketMQ Dledger) preserve state across failures.

Offline Scripts

Shortest lifecycle: a one‑shot job that runs, finishes, and the process terminates.

Problem‑Driven Solutions

Web

Handles traffic spikes with rate limiting, circuit breaking, and timeout‑retry. If downstream services fail, the front‑end quickly returns a friendly error page.

Message Queue

Accepts all upstream traffic, persists to disk, and allows downstream consumers to process at their own pace, providing natural "peak‑shaving".

CLI/Batch

Cannot horizontally scale like stateless web services; instead, it splits large jobs into independent tasks (MapReduce‑style) across many machines.

Consistency Guarantees

Web (Synchronous RPC)

In monoliths @Transactional suffices, but in micro‑services it forces distributed‑transaction frameworks (Seata, TCC, Saga) that dramatically increase latency (RT from tens of ms to hundreds) and reduce QPS.

Message Queue

Uses half‑message semantics (e.g., RocketMQ) to achieve eventual consistency while keeping high concurrency.

CLI

Relies on checkpointing and idempotent writes (e.g., ON DUPLICATE KEY UPDATE or globally unique UUIDs) to survive restarts and avoid duplicate data.

Decision‑Making Process for Real‑World Scenarios

When processing an order:

User clicks "Buy Now" – use synchronous RPC to create the order within ~500 ms.

After order creation, publish a message to MQ so inventory, marketing, and analytics services can work independently.

At night, run an offline script to aggregate sales, generate reports, and reconcile accounts.

Architects should ask three questions:

Can the user wait? → Sync RPC, async MQ, or offline script.

How large is the data? → Small → RPC; medium → MQ; massive → offline script with sharding.

How strong is the consistency requirement? → Strong → RPC + local transaction; eventual → MQ + compensation; batch reconciliation → offline script + idempotent writes.

Common Anti‑Patterns

Choosing a mechanism that does not match the problem, such as using synchronous RPC for operations that can tolerate delay, or deploying a message queue for trivial workloads, leads to wasted resources and poor user experience.

Extreme‑Load Guideline

When a system faces strict strong‑consistency requirements and tens of thousands of QPS, never try to force a synchronous web chain or rely on distributed transactions.

Instead, adopt a four‑step approach:

Make the web layer asynchronous – return "submitted" immediately.

Push the request into a durable MQ.

Let consumers process the messages at a steady pace, guaranteeing eventual consistency.

Use nightly CLI scripts to reconcile any residual discrepancies.

Conclusion

RPC, MQ, and offline scripts each have distinct OS interactions, I/O models, state management, and consistency strategies. Selecting the right tool starts with asking what the scenario values most: instant feedback, peak‑handling capacity, or batch compute. Matching the mechanism to the core requirement yields simpler, more reliable, and lower‑cost systems.