NOTE
1.11 Distributed-System Communication
Synchronous and asynchronous service communication, RPC versus resource-oriented HTTP APIs, API compatibility, and message encoding choices.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Why Distributed Services Need Communication
Once a system is split into independent services, one business operation may require communication across process or machine boundaries. That introduces network latency, partial failure, serialization, compatibility, retries, and observability concerns that do not exist in an in-process call.
2. Communication Styles
2.1 Synchronous Request/Response
Service A sends a request to service B and waits for a response. This is easy to reason about when an immediate result is required, but the caller’s latency and availability are coupled to the callee.
RPC vs. Resource-Oriented HTTP APIs
These are primarily interface styles, not fixed transport/encoding combinations.
| RPC style | Resource-oriented HTTP style | |
|---|---|---|
| Main abstraction | Operations/methods | Resources and representations |
| Contract | Often explicit IDL/schema | HTTP semantics plus API/schema definition |
| Transport | Can use HTTP/2, HTTP, TCP, or others | Usually HTTP |
| Encoding | Binary or text | JSON is common; other media types are possible |
| Client generation | Common | Optional |
RPC frameworks such as gRPC commonly use generated strongly typed clients, while HTTP APIs often emphasize standard HTTP methods and resource URLs.
2.2 Asynchronous Communication
The producer submits work or publishes an event without waiting for downstream processing to finish. Queues and event streams decouple availability and throughput, but callers must handle delayed outcomes, duplicates, ordering, retries, and eventual consistency.
3. API Compatibility
A semantic version such as MAJOR.MINOR.PATCH is useful when the project actually follows SemVer:
- MAJOR: incompatible changes;
- MINOR: backward-compatible functionality;
- PATCH: backward-compatible fixes.
For network APIs, compatibility rules should be defined at the schema/protocol level rather than inferred from version numbers alone.
4. Message Formats
Messages may use text encodings such as JSON or binary formats such as Protobuf. The choice affects readability, schema evolution, message size, tooling, and performance.