Web application architecture

Published in

On Coding

6 min readJan 14, 2015

Picking the web application architecture best suited to your unique needs is vital.

In this post I am going to talk about a few of the most common web application architectures you are likely to come across. Every web application has it’s own unique set of requirements and constraints so the architectures I will be listing here are just general examples. Your app might suit one of the architectures below, a hybrid or something completely different. This list is by no means exhaustive. I have explicitly excluded asynchronous architectures as that is a topic all on it’s own.

I’m also assuming your app has at least some server side logic and connects to some kind of database.

This post is part of a series, if you haven’t seen the previous posts in this series you can find them here:

Single web server

This is by far the simplest web application architecture and is hardly ever enough for a production application. Your HTTP server and database server live on the same machine behind your firewall. The advantage of this kind of setup is that it is extremely simple and is great for the early stages of a project where you don’t have any real users yet. The largest disadvantage is that you have a single point of failure. Single points of failure are places in your architecture where a single machine going down will cause your entire application to stop working. If you need to do a deployment or something goes wrong with your server users will not be able to access your application.

Single web server with separate database server

In this web application architecture we start to separate the HTTP application server from the database server. Once again this is not yet suited for a production application. You still have a single point of failure and can’t re-deploy your application without taking it offline. It does however set you up for a web farm and other more complex architectures.

Web farm

With this architecture we are starting to eliminate the HTTP server as a single point of failure. We do so by introducing a load balancer. Load balancing will distribute the incoming request between 2 or more servers. This spreads the load and also reduces the risk of a catastrophic outage by allowing multiple redundant servers to handle the workload. It is important to consider the fact that your load balancer might become a new single point of failure so a highly available load balancer is a good idea.

In this architecture our database is still a single point of failure. If your database goes offline for some reason you are still left with an application that is unable to service your users.

Web farm with a database cluster

By introducing a database cluster we eliminate the final single point of failure in our architecture. For any mission critical production system this is probably the simplest configuration that allows for a robust highly available system. I have intentionally left the details of the clustering vague as there are many many ways in which you could cluster a database. MySQL and MS SQL Server have their way of clustering while No SQL databases like MongoDB do it slightly differently. The important thing to understand is why you would want to cluster. The exact technical details of how to go about setting this up differs depending on the technology you are using.

Web farm with dedicated application servers

For more complicated scenarios where you have multiple subsystems and/or 3rd party systems (this is often the case for medium to large size corporates) you might start introducing application servers. Each web front end communicates with one or more application servers behind an additional firewall. For the sake of simplicity I have included only 1 application server per web server but it is quite feasible to have many application servers per web server. Often these are split by function for example payroll, billing, CRM etc. Splitting your solution up in this way allows you to keep the complexity of each subsystem lower.

Having an additional firewall allows you to create a DMZ (demilitarized zone). The purpose of the DMZ is to add an extra level of protection between potential intrusion from the internet and your internal systems. If a hacker where to compromise your web servers they would need to get through an additional firewall to gain access to highly sensitive internal data and systems.

In this architecture each HTTP server is mapped to a specific set of application servers. This eliminates the need for additional load balancers so it is slightly easier to set up infrastructurally. It does however bring a whole set of problems along with it. Configuration is more complicated and it is hard for the load balancer balancing the HTTP servers to know if a downstream app server is offline.

Web farm with load balanced application servers

This architecture is very similar to the previous one except that it introduces another load balancer. This simplifies configuration because all your HTTP servers can use the same IP address for each application server. It also makes scaling out easier. If one of your application servers is running near capacity you can add more instances to the cluster to help cope with the workload. In almost all cases it is desirable to have a load balancer between your HTTP servers and your app servers.

Conclusion

While these examples should give you a small taste of the forces acting on your architecture it is just that, a small taste. The important thing to remember is that each decision is a trade off. More redundancy at the expense of simplicity. Easy configuration at the cost of flexibility. You need to understand your environment and needs to be able to make the optimal trade offs for your situation. There is no such thing as a universally “good” architecture. There are only architectures that are appropriate or inappropriate for a specific set of constraints. These constraints evolve and change as your system grows and your user base grows so you should periodically re-visit your decisions and ensure they are still valid.

Originally published at syoung.org on January 13, 2015.