| Feature | Reverse Proxy | Load Balancer | API Gateway |
|---|---|---|---|
| Main purpose | A hotel’s concierge handles guest requests. | Distributes incoming network traffic across multiple servers. | Provides a single entry point for API requests to microservices. |
| Core task | Routes requests to the appropriate backend. | Distributes traffic to prevent server overload. | Manages requests and responses between a client and microservices. |
| Typical use case | Protecting a web server and handling tasks like SSL termination and caching. | Scaling a high-traffic application by distributing load. | Centralized management of APIs in microservices architectures. |
| Key features | * Hides backend server IP addresses * Provides SSL/TLS termination * Caches static content * Can perform basic load balancing. | * Uses algorithms to distribute traffic * Performs health checks on backend servers * Ensures high availability. | * Authenticates and authorizes requests * Enforces rate limits * Aggregates calls to multiple services * Manages API versioning. |
| Network layer | Primarily Layer 7 (Application Layer). | Can be Layer 4 (Transport Layer) or Layer 7. | Layer 7 (Application Layer), focused on API logic. |
| Market examples | NGINX, Apache, Cloudflare. | HAProxy, AWS ELB, Google Cloud Load Balancing. | Kong, AWS API Gateway, Apigee. |
How can they work together in a layered architecture
In complex systems, these components are often layered. A possible flow is: a client request goes through a global load balancer, then a local reverse proxy/load balancer, which forwards it to an API gateway. The gateway then directs it to an internal load balancer, which distributes it among microservice instances. The microservice processes the request and sends the response back through the same chain.