| Synchronous | Asynchronous |
|---|---|
| Request / Response | Public / (subscribe | async response) |
| Used mostly to communicate with other application | - |
| Remote procedure invocation-based | Message-based |
| REST, gRPC | AMQP, STOMP |
| Each request is processed by exactly one service | Can process by multiple services |
| Clients expect a timely response from the service | Response isn't sent immediately |
| Maybe blocking I/O | None-blocking I/O |
| services being tightly coupled | Less coupled |
| Less availability | More availability |
| Text-based message formats | Binary Message formats |
|---|---|
| JSON / XML | Protocol Buffers / Avro / Thrift |
| - | Force to use API-first approach |
| Human readabel/ self describing | - |
| Messages are verbose | - |
| overhead of parsing text | Focus on efficiency and performance |
| Pros | Cons |
|---|---|
| Simple | Request/Response style only |
| Easy to test via browser | Sender and Receiver must be running during the exchange. Hence, reduced availability |
| Firewall friendly | Clients must know the target URLs or Service discovery is needed |
| Doesn't require broker | - |
| Pros | Cons |
|---|---|
| efficient, compact, binary format | Older firewall might not support HTTP/2 |
| APIs evolve - easy on backward-compatibilities | More work for Javascript to consume gRPC-based API than REST/JSON |
| Interoperable between clients and services written in a wide rage of languages | - |
Using Remote procedure invocation style should consider
| Pros | Cons |
|---|---|
| Loose coupling | Potential performance bottleneck. (but modern brokers are designed to be highly scalable) |
| Message buffering | Potential single point of failure (but modern broders are designed to be highly available |
| Support both Sync and Async Request/Response | Additional operational complexity |
Potential design issue