A simple web application can be described using only a few components: the client, the web server, and DNS. The client sends requests, DNS helps locate the server, and the server processes those requests and returns a response.
Adding Persistent Data
Most real applications need to preserve information between requests and server restarts. To achieve this, we introduce another component: the database server.
Relational Databases
Relational databases organize information into tables made of rows and columns. Relationships can be created between tables, and SQL operations such as JOIN allow related information to be queried together. PostgreSQL and MySQL are common examples.
Non-relational Databases
Non-relational databases, often grouped under the term NoSQL, use data models other than traditional relational tables. These include document databases, key-value stores, graph databases, and wide-column databases. They can be useful when the data model is flexible or when the system has particular scalability requirements.
Vertical Scaling vs Horizontal Scaling
As traffic increases, the system may eventually need more resources. Two common approaches for dealing with this growth are vertical scaling and horizontal scaling.
Vertical Scaling
Vertical scaling means increasing the resources available to an existing machine. For example, we might add more CPU cores, RAM, or faster storage to the server.
“Instead of adding more servers, make the existing server more powerful.”
The main advantage is simplicity. The architecture usually does not need to change significantly. However, vertical scaling has physical and financial limits. A single machine can only become so powerful, and if that machine fails, the services running on it may become unavailable.
Horizontal Scaling
Horizontal scaling means adding more instances of a system component and distributing work between them. Instead of having one powerful web server, for example, we could run several web servers behind a load balancer.
This approach can improve scalability and availability. If one server fails, other instances may continue handling requests. Additional servers can also be introduced as traffic grows.
The trade-off is complexity. Multiple servers introduce problems such as load balancing, shared state, synchronization, caching, database replication, failure handling, and deployment coordination.
Scaling Different Parts of the System
Horizontal scaling is not one universal technique. Different components require different strategies. Web servers can often be replicated behind a load balancer, while databases might use read replicas, partitioning, or sharding. Caches and message brokers introduce their own approaches as well.
Because of this, vertical scaling is often a practical first step for smaller systems. Horizontal scaling becomes increasingly useful when traffic, availability requirements, or infrastructure constraints make a single machine insufficient.
Starting Simple
A system does not need to start with a complex distributed architecture. A client, web server, and database can support a significant amount of traffic when configured correctly. Scaling should usually be introduced when there is an actual bottleneck or reliability requirement rather than simply because the architecture might need it in the future.