A distributed system runs components on multiple networked machines that communicate through remote calls. This architecture enables scale across machines but introduces latency, uncertainty, and additional failure points. section 11.3 section 13.1.1
Designing a distributed system requires decisions about:
- Communication semantics: wait synchronously, continue while awaiting a response, or send a request without waiting. section 11.3.1
- Failure handling: distinguish unanswered requests caused by network failure, server failure, or a slow remote task. section 11.3.1
- Timeout coordination: prevent the caller from reporting failure while a remote service completes the operation, potentially creating duplicates. section 11.3.1
- Execution placement: use multiple machines to scale processing when the input or resource requirements exceed one machine. section 13.1.1
E-commerce order processing
An application server contacts retailers hosted on separate machines to find and order from a suitable shop. If the customer-facing request times out before the retailer responds, the retailer may still register the order; retrying can then create a duplicate. section 11.3 section 11.3.1
Figure 11.5 A more realistic design for the e-commerce application, taking into account the complexity of a distributed architecture and introducing a separate application server to deal with failures of HTTP calls to the shops’ servers
Use the architecture diagram to trace the application server, separate retailer machines, and remote HTTP calls that make failures part of the design. section 11.3
