System Design

Starting from the basics, each virtual machine instance can be considered a “node.”

With this, there are 3 ways to scale:

Vertical scaling — increasing available resources
Horizontal scaling — increasing nodes
Going serverless — auto-scaling instance provided by the CSP

Vertical scaling is going to generally be better for databases (i.e., Postgresql, MySQL, etc.). Its pitfalls are that it has a lower allocation ceiling and it costs more to allocate.

Horizontal scaling is going to be better for stateless nodes (e.g., REST APIs). Many nodes are unified into a single unit of operation called a “cluster.”

Serverless is going to be better for simple actions, such as baseless file serving. If the frontend is separated from the backend (e.g., React frontend, Rust backend), serverless will work. If the frontend is combined with the backend (e.g., Next.js frontend/backend), serverless will not be ideal.

When it comes to scaling databases, you can consider sharding or Master/Slave architecture.

Only do this if absolutely necessary – most of the time it’s extremely overkill.

Master/Slave architecture is where a single “Master” DB exists (r+w) and many “Slave” DBs exist (r-only). This is also referred to as a multi-node cluster. Failover can be achieved manually, semi-automatically, or automatically. When the Master DB is down, a Slave DB is promoted to Master to fill in its role. The Slave DBs all synchronize (copy) the Master DB for reading.

This leaves all write actions to the Master and all read actions to the Slaves for synchronized and high availability database access.