Topic 11.6
Synchronous Communication (REST/gRPC)
In one line
Request/response between services — the default, with gRPC as the high-performance option.
Think of it like this
Asking a question over a phone call and waiting on the line for the answer before you do anything else.
Key ideas
- 01
REST: HTTP, JSON, easy debugging, ubiquitous tooling — fine for most service calls.
- 02
gRPC: protobuf + HTTP/2 + streaming + codegen — for high-throughput or contract-strict internal traffic.
- 03
Sync implies the caller's latency = downstream latency; every nested call adds up (call graph depth).
- 04
Sync also implies failure propagation: downstream timeout → caller timeout unless handled (see 11.8-11.11).
- 05
Anti-pattern: long synchronous CHAINS (A→B→C→D); break with async or fan out in parallel.
- 06
Interview: 'user-triggered reads that need the answer → sync REST; background processing → async (next topic)'.
Java / Spring map
- →
Spring Cloud OpenFeign for typed REST clients; WebClient for reactive; grpc-spring for gRPC.
Code & diagrams
The caller's experience is the whole difference: does it wait, or does it move on?
Explain without notes
Why is a 4-deep synchronous chain a latency and reliability trap — show the numbers of 2× timeout cascades.
Practice
Convert a synchronous chain into 'call in parallel then join' and state the latency win.
Trade-offs
- ↔
Sync = simple reasoning + direct latency; async = resilience at consistency cost. They're complements, not rivals.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I choose sync/async per data freshness need and name the latency math.