Service Architecture Design Patterns
These pattern are useful when you are creating an API that will be called by 3rd party services or another software system.
These services are called from public networks.
Service-Oriented Pattern (SOP)
- Discrete business services.
- Use network to communicate.
- HTTP, XML, SOAP, binary.
| Pros | Cons |
| Business domain alignment | Clients must handle slow, offline network |
| High abstraction | Coarse interfaces |
| Discoverable, resilient | Many harm performance |
| Allow 3rd parties | Security issues |
| Cross-platform |
Microservice Pattern
Like SOA but with fine grained services,
- Services calling services
- Can use fast private network
- Deployed on multiple servers
| Pros | Cons |
| Modular | Must cope with slow, offline network |
| Reduced abstraction | More unanticipated cummunications |
| Discoverable, resilient | Hard to do transactions |
| Can use fast network | Hard to test, debug, & deploy |
| Less coarse interfaces |
Message-Bus Pattern
- Services connected to shared data bus
- Uses messages for communication
- Supports discovery, failover
| Pros | Cons |
| Easy to extend | Bus = single point of failure |
| Simple communication | Coarse communications |
| Very flexible | Can be slow |
| Easy to scale | Hard to test, debug |
| Easy discovery, failover |
