Premium

Service Communication Basics

Basic System Design
≈ 2 min read

A Network Call Is Not a Method Call

Inside one process, a method call usually either finishes quickly or reports an error immediately. Between services, things are different: the request crosses the network, the remote process can be overloaded, restarted, or completely unavailable, and the response can be delayed. 

Service A -> network -> Service B
             |
             +-> latency
             +-> timeout
             +-> connection error

That is why a service boundary should be treated as a separate contract with its own failure rules. A client must not assume that a remote service will always respond on time.

The Contract Matters More Than the Internal Implementation

Services communicate through an external interface: an HTTP API, an RPC contract, or a message format. As long as the contract remains compatible, the implementation behind it can change independently of the client.

A good contract clearly describes which input data is required, what is returned, which errors are expected, and which guarantees the operation provides. The less a client knows about the service internals, the easier it is to evolve both sides independently.

There Are Two Basic Ways to Hand Work Off

With synchronous communication, the caller waits for the result of the current request. With asynchronous communication, the work is passed on without requiring an immediate result. Both approaches are useful, but they create different time coupling and behave differently during failures.

A remote call is always more expensive than a local one. Even if an API looks like a regular method, the network, serialization, timeouts, and the independent lifecycle of another process are still there.
Back Next