Choosing right architecture for SaaS application

Industry trends like the shift from monolith applications to microservice architectures and extended scalability. SaaS and cloud services provide great opportunities to save expenses by reducing cost of maintenance in general. But when it comes to building SaaS application itself, a lot of architecture options are available and it is critical for project success to choose the right one.

In this article I will review most common architecture solutions on the example of SaaS API.

Initial project description

Let's assume we need to build an API with user registrations and corporate accounts which can be owned by single user and have other users as members.

Single-app architecture

Easiest way to create such application is to build a single-database application with properly structured key relations.

Image

This is the best way if the application does not tend to significantly grow in a short period or it will not require scaling to multiple servers or multiple regions.

Pros:

1. Easy maintenance of project within single codebase.
2. Consistend database structure.
3. Quick deployment.
4. Simple authentication management.

Cons:

1. Global project disfunction in case of errors.
2. Database maintenance and backup is harder with time.
3. Any client-oriented improvement requires updating the whole project.
4. Access management must be properly defined within application.

Split-database architecture

First thing that can be done to improve the case is to split architecture to multiple per-client databases.

Image

This allows to reduce need of access checks within code and ease database maintenance as far as any client-specific failure will not affect the whole service.

Pros:

1. Easier access management provided natively by database system.
2. Extended options for database maintenance and backup.
3. Improved scalability — databases can be placed on different servers.

Cons:

1. Requires more complex authorization system.
2. Database consistency may be violated.
3. Any client-oriented improvement still requires updating the whole project.
4. Application is still not flexible for load balancing and further scalability

Split-application architecture

Further development of project may require usage of several servers, client-oriented improvements or any kind of module-based system. Configuration of such environment with a single application instance is quite hard. What can be done here is to provide per-client application system.

Image

Pros:

1. Improved scalability — project is not bound to a single server anymore.
2. Load balancing may be provided by increasing amount of servers.
3. Any client application can be configured separately with needed modules and packages.

Cons:

1. Requires additional management systems for client application deployment.
2. Requires separate authorization server and internal integration of it to the apps.
3. Applications are not bound to a single IP/host anymore which may harden its usage.

Split-server architecture

Further growth of project usually requires using multiple servers for application groups. Mostly this is a requirement for regional expanding or performance optimizations.