Understanding the API Gateway An API Gateway is a server that acts as the single entry point for all clients. It provides a unified interface to a set of microservices, simplifies the client-side code, and hides the internal structure of the application. Here is a detailed breakdown of its functions: 1. Client Request Handling: The API Gateway receives HTTP requests from various client devices and applications. 2. Request Validation: It checks that the incoming requests are well-formed and have correct format and necessary parameters. 3. Access Control Lists: It implements allow-lists and deny-lists to control access to various services, preventing unauthorized requests from proceeding. 4. Authentication and Authorization: It interacts with authentication services to verify the identity of the requester and checks permissions to ensure they are authorized to access the requested resources. 5. Rate Limiting: It applies predefined rules to limit the number of requests a client can make within a certain time frame to prevent abuse and manage load. 6. Service Discovery: It identifies the appropriate services required to fulfill the request based on the request path, parameters, or headers. 7. Dynamic Routing: It directs the validated and authorized requests to the correct backend services. 8. Protocol Translation: It converts the request from the web-friendly protocols like HTTP/HTTPS to the specific protocols used by the backend services, if necessary. 9. Error Handling: It catches and handles any errors that may arise during the processing of requests, ensuring graceful degradation of service. 10. Circuit Breaking: It implements patterns to detect failures and prevent overloading the system, avoiding cascading failures in interconnected services. 11. Monitoring and Logging: It utilizes tools like the ELK stack for logging requests and responses, which is crucial for monitoring, tracing, and debugging. 12. Caching: It optionally stores responses to common requests, reducing the number of calls to the backend services. The API Gateway is an orchestration layer that manages request routing, composition, and protocol translation to provide seamless integration and efficient management of backend services. This is particularly important in microservices architectures where it simplifies client interactions with many services and enables the system to operate cohesively. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages): bit.ly/496keA7

HTTP/1 to HTTP/2 to HTTP/3 HTTP/1.0 was finalized in 1996. Every request to the same server requires a separate TCP connection which is expensive to establish. HTTP/1.1 (1997) introduced persistent connections, which allow a TCP connection to be reused for multiple requests and responses. This reduces the latency in setting up new connections for each request. But HTTP/1.1 doesn’t solve the head-of-line (HOL) blocking problem. Although HTTP/1.1 enabled pipelining, where multiple requests could be sent out without waiting for each response, the responses still had to be processed and sent back in the order the requests were received. This ordering requirement caused HOL blocking - if the first request took a long time, all later requests had to wait. HTTP/2 (2015) introduced HTTP streams - an abstraction that allows multiplexing different HTTP exchanges onto the same TCP connection. Streams don’t need to be sent in order. This eliminates HOL blocking at the application layer. But HOL still exists at the TCP transport layer. HTTP/3 draft was published in 2020. It uses QUIC instead of TCP as the transport protocol, removing HOL blocking in the transport layer. QUIC uses UDP. It introduces streams at the transport layer. QUIC streams share one connection, so no new handshakes or slow starts are necessary to create new streams. QUIC streams are delivered independently so packet loss usually doesn’t affect other streams. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages): bit.ly/496keA7