When to Use Service APIs vs Messaging: Picking the Right Integration Pattern

In system design we often use both standard service interfaces and standard messaging to transfer information and decouple components, but it is hard to decide which to use in a given scenario. Below are the characteristics of each (not a simple pros‑and‑cons list).

Standard Service Interface Interaction

High timeliness : latency equals method execution time. Strong consistency : direct calls are strongly consistent; SOA calls need distributed transaction support, providing clear execution results for further processing. Clear semantics: function name, parameters, return type, and purpose are obvious. Strong coupling : affected by downstream service SLA. Low extensibility : integrating new business logic requires additional code or configuration.

Standard Messaging Interaction

Loose coupling : only data dependency, no system dependency. Traffic buffering : can accumulate messages to protect downstream services. High extensibility : multiple consumers can subscribe without upstream changes. No direct interaction : only data transfer, execution result unrelated to upstream.

There is no universally best design, only the most suitable one. For example, in a content‑creation workflow, immediate safety checks give the best user experience, but current safety models take more than a few minutes, which is unacceptable for a latency‑sensitive front‑end app. Therefore the safety check should be decoupled: the content‑safety service validates asynchronously while the submission service ensures a smooth upload experience.

User Points System Points can be earned through various actions (orders, comments, shares). Since points and orders are unrelated domains, the points process should not affect order flow. Subscribing to order‑related events allows points to be tallied without the user perceiving the points mechanism.

Open Platform When collaborating with external developers, an open platform provides authentication, authorization, and routing. For example, a third‑party ERP syncing products to an e‑commerce platform must know when a product upload succeeds and receive the product ID to create promotions, requiring synchronous requests and responses.

Can the two approaches be combined? Yes, many systems use both service calls for time‑critical operations and messaging for asynchronous data propagation.

Full‑Link Tracing System Using Meituan’s open‑source Cat monitoring system as an example, Cat provides near‑real‑time metrics, health status, and alerts. Design requirements include fault tolerance (Cat failure should not affect business), high throughput, and real‑time data for fault detection. Specific monitoring scenarios include measuring code execution time, execution counts, periodic reporting of core metrics (memory, GC, thread count), and business‑critical KPIs (order count, transaction amount, payment success rate). Cat defines four explicit interfaces—Cat.newTransaction, Cat.logEvent, Cat.MetricForCount, and Cat.MetricForDuration—exposed via SDK for developers.

Another common scenario is task submission with feedback, such as generating a BI report. The system returns a task ID immediately, then notifies the caller upon completion.

Task Job System

Summary When you need a system to "do something" and care about the result, and timeliness is important, use a standard service interface for fast, synchronous interaction. If timeliness is not critical, consider an asynchronous job system that returns quickly and reports results later. When you only need data transfer or event awareness without affecting the upstream system, use standard messaging or events. If the data requires meaningful processing without impacting the source, follow the Cat monitoring pattern and submit processed data via SDK with clear semantics.

Source: https://www.jianshu.com/p/fb1356a9b542