The Fundamentals of SaaS Architecture Design

Looking to make the change from an on-prem solution to a Software as a Service (SaaS) offering? Your SaaS applications will be a set of services and features that are available in a hosted environment for your customers and clients. As you beginning designing your application requirement, there are a few decisions that will need to be determined in order to both provide a great experience for your clients as well as meet your business requirements. In this post, we will cover some of the decisions you will be make as you begin to design your SaaS architecture.

Which SaaS Deployment Model is Right for Me?

The tenancy and hosting model is the first decision you will need to make. Everything else around the choice of tools and tech stack will be influenced by this choice. Design decisions on whether to be single or multitenant will be important because each has a fundamentally different data and application isolation model among many differences. Results will vary depending on your requirements. Having flexibility of three distinct deployment models means you can tailor your deployment to your specific client requirements and operational requirements.

Every deployment will have certain trade-offs which must be considered. You will have to weigh the value of customization, operational efficiency, costs, and complexity with each approach.

This is why it’s critical to see how your use-cases align with your deployment model.

Single Tenant SaaS

In a single tenant SaaS architecture, each customer or tenant has their own dedicated instance of the application and underlying infrastructure. The application and database resources are isolated and dedicated to a specific customer, providing a higher degree of customization, control, and security. Each tenant operates within its own isolated environment, with separate databases, configurations, and data storage.

Single tenant SaaS architectures typically require more resources to manage and maintain, as each tenant’s instance needs to be individually provisioned, updated, and monitored. This approach is often suitable for customers with specific requirements or security concerns that necessitate dedicated resources.

Multi-tenant SaaS

In a multi-tenant SaaS architecture, multiple customers or tenants share a single instance of the application and underlying infrastructure. The application and database resources are shared among multiple tenants, enabling resource pooling and efficient resource utilization. In this architecture, tenants are logically isolated from each other, meaning their data and configurations are separated and secured.

The multi-tenant SaaS approach requires careful design to ensure data privacy, security, and scalability. It typically involves a shared database schema, where tenant data is segregated using mechanisms such as row-level or table-level isolation.

Multi-tenant architectures can be highly cost-effective over time with the right operational and design practices because of the use of shared infrastructure and centralized maintenance. However, customization options for individual tenants may be limited due to the need for standardized features and configurations.

Hybrid SaaS

A hybrid SaaS architecture combines elements of both single-tenant and multi-tenant architectures. It allows for a combination of dedicated instances at the application layer with shared infrastructure underneath, enabling flexibility to the needs of the customers or tenants.

Certain customers may require dedicated resources due to specific requirements, compliance regulations, or data sensitivity, while others may be able to share resources in a multi-tenant environment.

The hybrid SaaS architecture provides flexibility in accommodating different customer needs while optimizing resource utilization and cost-effectiveness. It requires careful management of the infrastructure and application components to ensure proper isolation and scalability for both dedicated and shared instances.

Composition of a SaaS Application Architecture

SaaS applications can be divided into logical and operational layers. The SaaS stack will be made up of an application layer, data layer, network layer, and security layer.

Each layer will have scaling capabilities, limitations, and requirements to map to your overall application design specification.

Application Layer

The application layer is responsible for delivering the core functionalities of the SaaS application to end users. It includes the presentation layer, business logic, and application components. This layer encapsulates the user interface, application workflows, and any customizations specific to the SaaS offering.

The primary objective of the application layer is to provide a seamless and intuitive user experience. This will include your web application servers, load balancers, and also any customer-facing APIs you have.

Data Layer

The data layer is concerned with the storage, retrieval, and management of data within the SaaS application. It comprises the database systems and any related infrastructure required for data persistence.

The data layer is responsible for ensuring data integrity, availability, and scalability. It includes mechanisms for data modeling, data access, and data manipulation, such as SQL or NoSQL databases. Proper indexing, caching, and replication strategies are often employed in this layer to optimize performance.

Network Layer

The network layer forms the foundation for communication and connectivity in the SaaS application. It involves the underlying network infrastructure, protocols, and technologies required for data transmission between the application and its users.

This layer handles aspects such as network topology, routing, load balancing, and traffic management. Additionally, it may incorporate content delivery networks (CDNs) to enhance the distribution of static and dynamic content.

A few things that you will need to plan and adjust for at the network layer

• Bandwidth and frequency of communication
• Inter-service communication
• Egress and ingress flow with potential for incurring usage costs

Network also naturally links to security requirements because it is the communication path for so much of the application traffic (both internal and external).

Security Layer

The security layer is essential to protect the SaaS application and its users from various threats and vulnerabilities. It encompasses measures to ensure data confidentiality, integrity, and availability.

This layer includes authentication mechanisms, access controls, encryption techniques, and secure communication protocols. It also involves implementing intrusion detection and prevention systems, firewalls, and security audits to mitigate risks and maintain compliance with industry standards.

Securing your data and infrastructure requires evaluating:

• Where data is supposed (and allowed) to be located
• Securing the data in flight and at rest
• Retention, resiliency, and information security practices
• Regulatory requirements specific to your industry and customers

Availability and resiliency tend to have common management tools and techniques but certain security measures are going to be purpose-built and operated by security teams outside the application itself.

When all of these logical layers work together harmoniously, they enable a SaaS application to function effectively, delivering value to users while maintaining the necessary security and scalability. The application layer focuses on providing a rich user experience, the data layer handles data storage and management, the network layer ensures seamless connectivity, and the security layer safeguards the application and its data from potential threats.

Now we go to the next step of designing our application data management strategy.

Active-Active vs Active-Passive

Active-Active and Active-Passive are two distinct approaches for implementing distributed databases. Public cloud makes it easy to do regional distribution of data, but there are always trade-offs between resiliency, performance, and cost.

Choosing Active-Active versus Active-Passive requires you to weigh the requirements of your application and business processes against the cost of resources.

Active-Active Distributed Database

In an Active-Active configuration, multiple database instances are actively serving client requests simultaneously. Each instance is responsible for handling a portion of the workload and maintaining its own set of data. The objective is to achieve higher scalability, fault tolerance, and load balancing across the instances.

Operating an Active-Active database has very stringent requirements to maintain data and system integrity. Here are the fundamentals of an Active-Active configuration.

Load Balancing

Active-Active databases utilize load balancers to distribute client requests across multiple instances. The load balancer ensures that incoming requests are evenly distributed to each instance, balancing the workload across the system.

Data Partitioning

The database can also be partitioned with each instance holding a subset of the data. Data partitioning can be based on various strategies, such as range partitioning, hash partitioning, or sharding. Each instance is responsible for managing its own portion of the data and processing queries related to its partition.

Partitioning is also bound by service limits and system constraints. Data, compute, and network generally have hard limits set by your cloud or on-premises providers. This will be critical in understanding how the design and the implementation come together.

Data Consistency

Maintaining data consistency is crucial in Active-Active configurations. Techniques like distributed transactions, two-phase commit protocols, or eventual consistency mechanisms are employed to ensure data integrity across the distributed database instances. Synchronization techniques, such as replication or data synchronization protocols, help keep the data consistent across all instances. This is especially important for structured ACID compliant databases because unstructured data (e.g. key-value stores, document databases) generally relies on eventual consistency and applications are designed accordingly.

Conflict Resolution

In Active-Active setups, conflicts may occur when concurrent updates are made to the same data item on different instances. Conflict resolution mechanisms, such as timestamp-based ordering or conflict detection and resolution algorithms, are implemented to reconcile conflicting updates and maintain data consistency.

There are benefits for Active-Active that can make this an attractive design pattern. These advantages do have some trade-offs but an Active-Active design may be the optimal approach depending on your application requirements.

Scalability

Active-Active configurations allow for horizontal scalability by distributing the workload across multiple instances, enabling better performance and handling of high traffic volumes.

High Availability

In the event of failure of one instance, other instances continue to serve client requests, ensuring continuous availability of the system.

Load Balancing

By distributing the workload across multiple instances, Active-Active configurations achieve load balancing, ensuring optimal utilization of resources.

Active-Passive Distributed Database

In an Active-Passive configuration, one database instance serves as the primary active instance, handling client requests, while one or more standby instances remain passive, ready to take over if the active instance fails. The primary objective is to ensure high availability and quick failover in case of primary instance failures.

There are different technical requirements for Active-Passive compared to an Active-Active configuration which is far more latency sensitive.

Primary-Secondary Relationship

The active instance, or the primary database, handles all read and write operations from clients. The passive instances, or secondary databases, remain synchronized with the primary database by replicating data changes. Replication mechanisms, such as log shipping, transactional replication, or database mirroring, are commonly used to keep the standby instances up-to-date.

Failover Mechanism

In the event of a failure of the active instance, a failover mechanism is triggered to promote one of the standby instances as the new active instance. This process involves redirecting client connections, ensuring data synchronization, and activating the appropriate services to resume database operations.

Data Consistency

Active-Passive configurations focus on maintaining data consistency between the active and standby instances. Replication mechanisms ensure that changes made on the primary instance are properly propagated to the standby instances, ensuring data integrity.

Monitoring and Automatic Failover

Continuous monitoring of the primary instance’s health and automatic failover mechanisms are often implemented to minimize downtime. If the primary instance becomes unresponsive, the failover mechanism automatically switches to one of the standby instances to minimize service disruption.

In the next part of this series, we will look at building and designing high-performance SaaS applications.