Scaling the API
This chapter finishes designing the registrar’s course catalog API, deciding how it performs under load and how it changes over time, then scales it as its traffic grows. It covers pagination, caching, rate limiting, versioning, documentation, and REST as an architectural style, then duplicating the API’s server, splitting it by function, and routing between the pieces with a gateway.
After reading this chapter, you should be able to:
- Design paging, caching headers, and rate limits from the response size, freshness, isolation, and fairness requirements
- Distinguish safe changes from breaking changes and explain how a version in the base URL keeps an old client working
- List what an API’s documentation must contain for a developer to make a first request without help
- Name the constraints of REST and say which ones a practical RESTful API meets
- Explain how two systems with an API between them fail, change, scale, and are owned separately
- Explain how load shedding trades against availability, and how growth in traffic puts the isolation, fairness, and availability requirements in tension on shared hardware
- Describe duplicating a server behind a load balancer as horizontal scaling, and distinguish the designer’s decision to duplicate from the operational job of running and sizing the instances
- Trace a request through a load balancer to an instance and back, and name load balancing strategies and autoscaling without their implementation details
- Define functional decomposition, distinguish it from duplication, and explain why splitting two services requires renegotiating a hosting constraint that duplication did not
- Trace a request through an API gateway to the correct service and back, and distinguish what a gateway routes on from what a load balancer routes on
- Combine duplication and functional decomposition into one architecture, and state a rule of thumb for choosing among vertical scaling, horizontal scaling, and functional decomposition