// Tutorial //

5 Common Server Setups For Your Web Application

Published on May 30, 2014
Default avatar
By Mitchell Anicas
Developer and author at DigitalOcean.
5 Common Server Setups For Your Web Application


When deciding which server architecture to use for your environment, there are many factors to consider, such as performance, scalability, availability, reliability, cost, and ease of management.

Here is a list of commonly used server setups, with a short description of each, including pros and cons. Keep in mind that all of the concepts covered here can be used in various combinations with one another, and that every environment has different requirements, so there is no single, correct configuration.

1. Everything On One Server

The entire environment resides on a single server. For a typical web application, that would include the web server, application server, and database server. A common variation of this setup is a LAMP stack, which stands for Linux, Apache, MySQL, and PHP, on a single server.

Use Case: Good for setting up an application quickly, as it is the simplest setup possible, but it offers little in the way of scalability and component isolation.

Everything On a Single Server


  • Simple


  • Application and database contend for the same server resources (CPU, Memory, I/O, etc.) which, aside from possible poor performance, can make it difficult to determine the source (application or database) of poor performance
  • Not readily horizontally scalable

Related Tutorials:

2. Separate Database Server

The database management system (DBMS) can be separated from the rest of the environment to eliminate the resource contention between the application and the database, and to increase security by removing the database from the DMZ, or public internet.

Use Case: Good for setting up an application quickly, but keeps application and database from fighting over the same system resources.

Separate Database Server


  • Application and database tiers do not contend for the same server resources (CPU, Memory, I/O, etc.)
  • You may vertically scale each tier separately, by adding more resources to whichever server needs increased capacity
  • Depending on your setup, it may increase security by removing your database from the DMZ


  • Slightly more complex setup than single server
  • Performance issues can arise if the network connection between the two servers is high-latency (i.e. the servers are geographically distant from each other), or the bandwidth is too low for the amount of data being transferred

Related Tutorials:

3. Load Balancer (Reverse Proxy)

Load balancers can be added to a server environment to improve performance and reliability by distributing the workload across multiple servers. If one of the servers that is load balanced fails, the other servers will handle the incoming traffic until the failed server becomes healthy again. It can also be used to serve multiple applications through the same domain and port, by using a layer 7 (application layer) reverse proxy.

Examples of software capable of reverse proxy load balancing: HAProxy, Nginx, and Varnish.

Use Case: Useful in an environment that requires scaling by adding more servers, also known as horizontal scaling.

Load Balancer


  • Enables horizontal scaling, i.e. environment capacity can be scaled by adding more servers to it
  • Can protect against DDOS attacks by limiting client connections to a sensible amount and frequency


  • The load balancer can become a performance bottleneck if it does not have enough resources, or if it is configured poorly
  • Can introduce complexities that require additional consideration, such as where to perform SSL termination and how to handle applications that require sticky sessions
  • The load balancer is a single point of failure; if it goes down, your whole service can go down. A high availability (HA) setup is an infrastructure without a single point of failure. To learn how to implement an HA setup, you can read this section of How To Use Reserved IPs.

Related Tutorials:

4. HTTP Accelerator (Caching Reverse Proxy)

An HTTP accelerator, or caching HTTP reverse proxy, can be used to reduce the time it takes to serve content to a user through a variety of techniques. The main technique employed with an HTTP accelerator is caching responses from a web or application server in memory, so future requests for the same content can be served quickly, with less unnecessary interaction with the web or application servers.

Examples of software capable of HTTP acceleration: Varnish, Squid, Nginx.

Use Case: Useful in an environment with content-heavy dynamic web applications, or with many commonly accessed files.

HTTP Accelerator


  • Increase site performance by reducing CPU load on web server, through caching and compression, thereby increasing user capacity
  • Can be used as a reverse proxy load balancer
  • Some caching software can protect against DDOS attacks


  • Requires tuning to get best performance out of it
  • If the cache-hit rate is low, it could reduce performance

Related Tutorials:

5. Primary-replica Database Replication

One way to improve performance of a database system that performs many reads compared to writes, such as a CMS, is to use primary-replica database replication. Replication requires one primary node and one or more replica nodes. In this setup, all updates are sent to the primary node and reads can be distributed across all nodes.

Use Case: Good for increasing the read performance for the database tier of an application.

Here is an example of a primary-replica replication setup, with a single replica node:

Primary-replica Database Replication


  • Improves database read performance by spreading reads across replicas
  • Can improve write performance by using primary exclusively for updates (it spends no time serving read requests)


  • The application accessing the database must have a mechanism to determine which database nodes it should send update and read requests to
  • Updates to replicas are asynchronous, so there is a chance that their contents could be out of date
  • If the primary fails, no updates can be performed on the database until the issue is corrected
  • Does not have built-in failover in case of failure of primary node

Related Tutorials:

Example: Combining the Concepts

It is possible to load balance the caching servers, in addition to the application servers, and use database replication in a single environment. The purpose of combining these techniques is to reap the benefits of each without introducing too many issues or complexity. Here is an example diagram of what a server environment could look like:

Load Balancer, HTTP Accelerator, and Database Replication Combined

Let’s assume that the load balancer is configured to recognize static requests (like images, css, javascript, etc.) and send those requests directly to the caching servers, and send other requests to the application servers.

Here is a description of what would happen when a user sends a requests dynamic content:

  1. The user requests dynamic content from _http://example.com/_ (load balancer)
  2. The load balancer sends request to app-backend
  3. app-backend reads from the database and returns requested content to load balancer
  4. The load balancer returns requested data to the user

If the user requests static content:

  1. The load balancer checks cache-backend to see if the requested content is cached (cache-hit) or not (cache-miss)
  2. If cache-hit: return the requested content to the load balancer and jump to Step 7. If cache-miss: the cache server forwards the request to app-backend, through the load balancer
  3. The load balancer forwards the request through to app-backend
  4. app-backend reads from the database then returns requested content to the load balancer
  5. The load balancer forwards the response to cache-backend
  6. cache-backend caches the content then returns it to the load balancer
  7. The load balancer returns requested data to the user

This environment still has two single points of failure (load balancer and primary database server), but it provides the all of the other reliability and performance benefits that were described in each section above.


Now that you are familiar with some basic server setups, you should have a good idea of what kind of setup you would use for your own application(s). If you are working on improving your own environment, remember that an iterative process is best to avoid introducing too many complexities too quickly.

Let us know of any setups you recommend or would like to learn more about in the comments below!

If you’ve enjoyed this tutorial and our broader community, consider checking out our DigitalOcean products which can also help you achieve your development goals.

Learn more here

About the authors
Default avatar
Developer and author at DigitalOcean.

Still looking for an answer?

Was this helpful?

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

And Google App Engine gives all of that for free, plus

  1. Master-master replication, which gives you almost infinite horizontal scaling.
  2. Automatically replicates your data over datacenters/continents, so even whole datacenter failure won’t make your unavaliable.
  3. Serves static content (HTML, CSS, JS, images) without even touching your server, from Google’s distributed Content Delivery Network.
  4. Secures HTTPS requests automatically, no need to obtain/install/manage SSL certificates.
  5. Many more.

And all of that automatically, you don’t worry how it works inside.

@dan / @kiru42: The easiest way to avoid having the load balancer be a single point of failure is to set up an active/passive HAProxy pair. This would require two HAProxy servers and a virtual/floating IP that can move between the two servers. The active HAProxy server would handle all of the requests unless it went down, at which point the passive HAProxy server would take over the requests. This is a high availability (HA) setup.

DigitalOcean, similarly to many other hosting providers, does not currently support floating IP addresses.

Some people suggest using round robin DNS to workaround not having floating IP addresses, but it is not a true HA setup for a variety of reasons. I do not recommend it because there are situations where it can actually decrease your availability. If you would like to experiment with it anyway, here is a tutorial: https://www.digitalocean.com/community/articles/how-to-configure-dns-round-robin-load-balancing-for-high-availability

@dlazerka whilst we’re at it, why don’t we suck all of the fun out of the web development as well, and just go for a prebuilt system? Recommending people use something out of the tin rather than learning how it works is setting them up for failure. Live a little, learn a little.

#5 could be it’s own article.

lovely article though.

I’m starting in this ultra immense world and I’ve got to say this is, by far, the best post I’ve found.

By the way, can anyone tell me where can I find that network topology icons? I would love to use them in my projects.

Thanks in advance.

PS: Again, GREAT post.

@dlazerka nothing is ‘free’ - yes perhaps Google App Engine might offer it for free to start with, but then as soon as you actually need to scale, and start handing hundreds of thousands of queries per hour, you will soon start paying. Knowing how to set this up using bare metal hardware or cloud instances might save you a lot of money, Google charge a premium for all of this of course.

Then there is the fact that you’re locked into their system, so once things start costing a lot then you will have to jump through hoops to get your app and data migrated and its never easy.

I’m guessing you’ve probably never actually built anything that needs any kind of scale anyway :)

Well explained, thanks!

Very good article. While researching the best configuration for our production server, I reached this article. So I’m putting my requirement here and see if any expert here could suggest me a best economic hosting plan either in Digital ocean or else where.

We are planning to launch our application in production once all the testing is completed after deployment to our development server. We are using Jenkins CI automation to deploy the code to the development server and we will do the same in production server too, but we are currently doing a feasibility study to understand which Digital Ocean or other hosting options are good for Django Web and Mobile eCommerce app. This app is meant for both consumers and businesses for consumer shopping and lead generation to businesses. That means traffic is anticipated heavily if the app gets popular hopefully.

Best regards

Great article!

If I want to implement no. 3, the loadbalancer reverse proxy, and the website is just WordPress based e-commerce website, what should be the app-2?

Assuming the app-1 is the WP website itself.

Where should i install the caching plugins, etc? app-1 or app-2?

Valuable content. Thanks, Mitchell.

Thanks, Digital ocean.