Understanding SaaS Architecture: Layers, Multi‑Tenant Design, and Core Components

SaaS Overview

SaaS (Software‑as‑a‑Service) delivers software on a subscription basis, allowing users to rent functionality on demand instead of purchasing, installing, and maintaining on‑premise applications. The model shifts installation, upgrades, and maintenance to the provider, while users access the service over the internet, paying monthly fees.

Layered Architecture

Presentation Layer

Clients may be web browsers (requiring HTML5, CSS3, Ajax, etc.) or native applications (requiring remote‑desktop or other interaction technologies).

Scheduling Layer (Tenant Identification)

This layer implements distributed‑system features, often using a configuration center to store tenant‑specific settings and version information. Tenant authentication can be done with a Spring interceptor that stores the tenant ID in a ThreadLocal for downstream processing, enabling horizontal scaling.

Business Layer

The business layer receives requests from the scheduling layer and executes the core logic. It typically runs on a pool of identical servers, keeping database and cache access transparent to developers.

Data Layer

Relational database clusters handle highly transactional data, while distributed databases store large, less‑relational datasets such as operation logs. Data is partitioned according to business characteristics.

Core SaaS Components

Security Component : Protects tenant data, similar to banking security.

Data Isolation Component : Ensures each tenant’s data remains invisible to others.

Configurable Component : Allows tenants to customize UI layout, themes, logos, and other settings.

Scalable Component : Supports horizontal scaling via load balancers and container orchestration; vertical scaling is also possible but less efficient.

Zero‑Downtime Upgrade Component : Enables upgrades without taking the service offline.

Multi‑Tenant Component : Guarantees that multiple tenants can share the same instance safely and independently.

SaaS Maturity Model

Level 1 – Custom development: a separate instance per customer.

Level 2 – Configurable: all customers run the same version; customizations are configuration‑driven.

Level 3 – High‑performance multi‑tenant (Highrise): multiple customers share a single instance.

Level 4 – Scalable multi‑tenant (Build‑Out): same shared instance with scale‑out hardware expansion.

Multi‑Tenant Data Storage Strategies

Isolated databases per tenant.

Shared database with isolated schemas.

Shared schema with a tenant_id column (recommended).

Data isolation must be transparent to the application.

Tenant Identification and SQL Handling

Naïve SQL modification (adding AND tenant_id = 1) is error‑prone. A better approach rewrites SQL in the data‑access layer:

select username,password from users where email='[email protected]'

At runtime the framework rewrites the statement using a TenantContext:

TenantContext.exec("select username,password from users where email='[email protected]'");

This centralizes tenant filtering, prevents leaks, and simplifies future sharding.

Performance and Security Optimizations

Database: proper indexing, avoid large joins, simplify complex queries.

Application: caching, asynchronous processing, tenant‑aware search indexes.

Presentation: front‑end performance tuning.

Security: authentication, authorization, audit logging, encryption, secure network transport.

Additional Considerations

Tenant identification can be domain‑based (e.g., abc.crm.example.com) with optional CNAME mapping, or login‑name based if domains are not used. Custom development should be modular, with separate services per tenant feature and front‑end routing via Nginx. Gray‑release strategies use domain or Nginx‑Lua routing to limit impact of new versions.

Typical SaaS functional requirements include software licensing, organization onboarding, real‑name verification, credential audits, organization binding/unbinding, account deletion, SSO, and unified registration.