Consider a typical design of a web application where some parts are running on the backend side, and some on the client side. This system is composed of the following:

• A web application running on a client device (a PC or a smartphone)
• Several features running on the backend side, and an HTTP server hosting static files

Depending on the complexity of the system, the backend part can be implemented either as a unique service or as several services. Using a unique service was the dominant design in the early 2000s. However in practice, splitting them into multiple independent services has many benefits. The main one is the fact that these components can be operated independently. They can also be written in different programming languages, using different technologies.

With the backend side of applications getting more and more complex, and the fact that most applications rely on much more than a few independent services, the split in multiple services is more and more popular. This split in many services is called a microservice architecture. It is a design where many small services are combined together, while being independent of each other as much as possible.

Splitting an application into many small services is fine, but this should not add complexity to the client side: All these services should be accessible as if they were a single service. More specifically, these services should be available via the same domain name. So, deciding on what service each HTTP request should be routed to has to be done via the URI of the request. In the case of an application running two services, one possibility is to do the following:

• Route all requests to /api/a to service A
• Route all requests to /api/b to service B
• Route all other requests to a web server to serve static files

This routing is the role of a reverse proxy. The use of a reverse proxy for this example application is shown in the following figure:

The reverse proxy is in between the client and the services. It receives all requests from the clients, and forwards them to each service, based on the information in the incoming HTTP requests. The routing decision can be done via different criteria:

• The path of the request
• The query part of the request
• The (sub) domain name being requested
• The headers present in the request
• The method of the request

So, a reverse proxy takes its name from the fact that it works in the opposite way to an HTTP proxy. The following figure shows how an HTTP proxy works:

A proxy filters outgoing requests from clients to websites/applications. It operates on the network of the client devices. A reverse proxy filters incoming requests from clients to the backend services. It operates on the network of the application provider.

So, a reverse proxy is a tool that simplifies the deployment of applications that are composed of several services running on the backend side. Originally, reverse proxies were used when several web domains or sub-domains were hosted on the same IP address. Using the criteria listed previously allows us to route each request correctly. Now, the same tools are used to route requests to web services.