Build a scalable architecture for a news website using the components below:

  • A load balancer with content-switching capability

  • Cache server

  • Application server

Content Switching Definition

  • Content switching: the ability to route traffic based on the content of the HTTP request: URI, parameters, headers, etc. HAProxy is a good example of an open-source reverse proxy load balancer with content-switching capability.

  • Cache server: a server able to quickly deliver static content. Squid, Varnish, and Apache Traffic Server are open-source cache reverse proxies.

  • Application server: the server which builds the pages for your news website. This can be either Apache+PHP, Tomcat+Java, IIS+asp .net, etc…

Target Network Diagram

archi content switching diagram

All the traffic passes through the Aloha load balancer. HAProxy, the layer 7 load balancer included in Aloha, will do the content switching to route requests either to cache servers or to application servers.
If the cache server misses an object, it will get it from the application servers.

Similar Articles:

HAProxy Configuration

Service configuration:

frontend public
	bind :80
	acl DYN path_beg /user
	acl DYN path_beg /profile
	acl DYN method POST
	use_backend APPLICATION if DYN
	default_backend CACHE

The content switching is achieved by the few lines beginning with the keyword acl. If a URI starts with /user or /profile or if the method is a POSTthen, the traffic will be redirected to the APPLICATION server pool. Otherwise, the CACHE pool will be used.

Application pool configuration:

backend APPLICATION
	balance roundrobin
	cookie PHPSESSID prefix
	option httpchk /health
	http-check expect string GOOD
	server APP1 1.1.1.1:80 cookie app1 check
	server APP2 1.1.1.2:80 cookie app2 check

We maintain backend server persistence using the cookie sent by the application server, named PHPSESSID in this example. You can change this cookie name to the cookie provided by your application, like JSESSIONID, ASP.NET_SessionId or anything else.

Note the health check URL: /health. The script executed on the backend will check server health (database availability, CPU usage, memory usage, etc…) and will return a GOOD if everything looks fine and a WRONG if not. With this, HAProxy will consider the server as ready only if the server returns a GOOD.

Read More: How to Enable Health Checks in HAProxy

Cache pool configuration:

backend CACHE
	balance url
	hash-type consistent
	option httpchk /
	http-check expect KEYWORD
	reqidel ^Accept-Encoding unless { hdr_sub(Accept-Encoding) gzip }
	reqirep ^Accept-Encoding: .*gzip.* Accept-Encoding: gzip
	server CACHE1 1.1.1.3:80 check
	server CACHE2 1.1.1.4:80 check

Here, we balance requests according to the URL. The purpose of this metric is to “force” a single URL to always be retrieved from the same server.


The main benefits are :

  1. less objects in caches memory

  2. less requests to the application server for static and pseudo-static content

In order to lower the impact of the Vary: header on Content Encoding, we added the two lines reqidel / reqirep to normalize a bit the Accept-Encoding header.

Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.