Database as a bottleneck

We've so far learned how to increase the number of servers and looked into ways of increasing the perceived performance of the servers. We haven't considered scaling of the database beyond caching database queries, however. In web applications, the database is often a large contributor to the perceived performance, as it is a separate system that needs to be queried on demand.

In our applications so far, we've used a single database, which is acceptable for small applications. This is shown in Figure 1, which highlights the use of a single database for two servers.

Note that having a single database server in production use is not recommended, as it is a single point of failure. For the purposes of the present course, we've used a single database server for simplicity.

Increasing the number of servers that access the database is not as straightforward as increasing the number of web servers. The database is a bottleneck, as it can only handle a limited number of connections. With an increasing number of connections, the database eventually cannot handle the load. Figure 2 demonstrates a situation where multiple servers access a single database.

As we've learned in the Web Software Development course, it is meaningful to utilize a connection pool to manage connections to the database. Each connection in a connection pool is essentially an open connection to the database that can be borrowed from the pool and returned to the pool when no longer needed.

In this chapter, we're looking into some basic priciples of increasing database performance, the properties of databases, and the main ways of distributing database data. Concretely increasing the number of database instances is looked into later when considering container orchestration.