1. Building a SaaS Style Application
SaaS Patterns – A Problem-Solution Approach
Abstract
Software as a Service (SaaS) adoption is on the rise in the enterprise world, driven largely by its
promise to deliver „capital expenditure avoidance‟, „quicker time-to-market‟ and „reduced risk‟. To
capitalize on the SaaS wave, Independent Software Vendors (ISVs), Service Providers (SPs) and Service
Centered Businesses (SCBs) are quickly moving to deliver service from the Enterprise Cloud [1]. Usually,
such vendors are focused on product/service features and not on serviceability. This makes the
challenges in transition to a „SaaS Provider‟ easier said than done. This article discusses 7 Key
Challenges in architecting software to be delivered as a service.
Introduction
If you are in the software industry, chances are that you have heard the term SaaS by now. Companies
like Salesforce.com have been extremely successful in bringing this concept to reality and opening up
untapped markets for business.
Chances are very unlikely that you will be constructing a full blown SaaS application to be marketed
worldwide; but you can take key concepts from „SaaS Construction‟ and build your next in-house
application in SaaS style, still reaping most of the SaaS architectural benefits. You will be amazed that
any Google search on SaaS throws up hundreds of results on the business side of SaaS and very little on
the technical side. While one can get low level technical details on the data modeling side of SaaS from
the Microsoft website, as a technologist you will need more patterns to jumpstart your SaaS journey.
The following article is a compilation of my thoughts to fill the void I found.

2. ‘SaaS Patterns – A Problem-Solution Approach’
1. Problem (Database)
Business problem: How can business lower the „cost of service‟ without compromising on QoS?
Technical cause: Can a single database instance be used to capture many client‟s (tenant) data,
thereby promoting economies of scale? How will architectural attributes like Performance,
Extensibility, Security, Customization, etc… handled in multi tenancy?
Solution
A simple, yet elegant solution, to this problem is to insert Client Id (Tenant Id) as an additional column
in each table storing multi-tenant data. Now, how do you make this solution cope with extensibility,
performance and security requirements?
Extensibility: For extensibility, the data in the database can be held in an XML CLOB without defining a
hard schema. As extensible as XML is, it brings its own downsides in CRUD operations – XML queries are
relatively slow and cumbersome. If XML is not a preferred option, you can design tables with generic
columns or extension tables (tree structure) for handling extensibility.
Performance: Generic design and performance generally don‟t go very well together. In most
instances, to scale one you have to sacrifice the other. One workaround to this problem is to
accommodate key search fields within the data model. This will assist in faster SQL-based querying.
Security will be handled in the next section.
Fig 1. Tenants having a separate database each versus a shared multi-tenant database in SaaS

3. 2. Problem (Database - Security)
Business problem: How will the customer‟s „IP Protection‟ & „Data Security‟ be guaranteed?
Technical cause: How will data security be enforced at the Architecture level? Every resource
should be locked down with the tenant details, so that even if hacked by application developers one
tenant‟s data should not be made available to others.
Solution
You cannot protect something if you do not know where it is. So, the first step in ensuring client data
security is to add a Tenant ID column to all the tables in the database. However, this alone is not going
to provide the required level of security - we cannot rely on developers who write the queries to be
mindful of security concerns.
The next level of securing client data involves preventing unauthorized access at the database level.
This requires some kind of support at the database level.
To achieve this in a SQL Server environment:
1. Restrict direct access to tables for tenants; administrators can be given direct access
2. Create a unique database ID for each tenant
3. Map tenant ID to database ID in a particular table
4. Create table valued functions which take the tenant ID and return the data as a table
5. Create a view that calls the table valued function
6. Give access to the view for tenants
If you are using an Oracle database, then Oracle‟s Virtual Private Database (VPD) / Oracle Label
Security (OLS) can be used to come up with a solution. Similar implementations are feasible in MySQL.
The advantages of this approach are that security is handled at the architecture level and is fool proof
from hackers. Additionally, there is no overhead for developers and it provides for transparent handling
of tenant details.
Fig 2. Security relying on Tenant‟s good intent versus security enforced at database level in SaaS

4. 3. Problem (Meta Data Services)
Business problem: How can SaaS service providers be agile to their customer‟s needs?
Technical cause: How can configuration data kept minimum thereby enabling simplicity? Every
component in the system can have its own configuration structure ending up in a separate file or table.
The meta-data will increase exponentially as the number of components & number of tenants rise.
Solution
Most components have their default meta-data values and tenants do not always override the default
setting. In many situations, a hierarchy of default values exists. For example, a company can set some
default settings, and at the next level a department can have its own settings, etc.
Now, we end up with two main themes
1. Meta-data hierarchy (e.g. user-department-branch-country-company)
2. Overriding Priority (In a meta-data hierarchy, some features have top-down priorities while
others have bottom-up priorities)
Meta-data services should handle highly configured component meta-data and less configured meta
data in slightly different ways.
The following solution is applicable for meta-data with low levels of tenant overriding. (While the
solution discusses configuration files only, the same applies to database configurations as well.)
1. The default component meta-data should be stored in the application level folder structure.
2. A similar folder structure should be maintained for every client who overrides the default data
- note that only the files that are overridden should be saved for that tenant.
3. At the time of client login or application startup, the meta-data service should load all the
tenant hierarchy and tenant specific configuration and super impose them in the right order to
obtain the tenant-specific data.
Meta-data services can also exhibit an event notification mechanism using the “publish-subscribe
pattern”, where any changes to the meta-data can be communicated to the layers above.
Note: Depending on the complexity of the solution the meta data services component can be build
from ground up or a FOSS framework like Obix, JFig, etc… which can be used/extended.

5. Fig 3. Hard coded logic in component for handling multi-level configurations versus a generic &
structured approach to multi-level user/tenant level meta-data handling in SaaS

6. 4. Problem (Tenant aware Controller)
Business Problem: What technical assets will speed up a SaaS service provider‟s time to market?
Technical cause: How can the application controller navigate the tenant to the next tenant
specific step? Navigation can range from a high level of navigating from the business logic to the view
or business logic to data access or any macro level step.
Solution
Navigating or Tenant Flow Orchestration is an extension of the Controller component from the MVC
design pattern. The Controller has the base flow or orchestration configured.
Within a SaaS framework, we need to slightly change the way the Controller handles event
orchestration. When the Controller receives a service request, instead of directly handing over to the
next step, the Controller should call the meta-data services to get the reference for the next step.
When there is customization or overriding performed at the tenant level, the meta-data services will
return this information which will be used by the Controller for orchestration.
For example, a business service A may have AI.jsp as the input screen and AO.jsp as the output screen.
If this action requires customization for 5 clients with different input & output pages, one way to
handle this is to hard code the input & output jsp in the controller XML under 5 customized actions. A
much better way of doing this is to have one service A defined with logical input & output pages and
let the controller get the absolute pages from the meta-data services.
Fig 4. Controller in MVC referring to absolute resources versus a Logical controller doing absolute
resource mapping with the help of a meta-data services layer in SaaS

7. 5. Problem (Infrastructure Services / Setup)
Business problem: How to guarantee „High Scalability & High Availability‟ of my SaaS service?
Technical cause: Even though SaaS promotes economies of scale through multi tenancy at times
we could be forced to take tenant specific actions to achieve scalability and availability.
Solution
Having a group of application clusters and letting all tenant users hit servers through a load balancer is
a simple solution which will work for most SaaS implementations. However, the service provider might
also have a tiered Tenant model and/or different SLAs for different tenants. In the latter case, you will
encounter the following specific requirements from the infrastructure deployment:
1. Performance & Scalability throttling based on Tenant Priority
2. Reduced static deployment downtime based on Tenant Priority
The solution is to form tenant clusters, so that there is segregation of tenants by priority and SLA
requirements. To achieve this routing you need a “Tenant Aware Load Balancer” to route requests
appropriately. The login authentication could be done on a common server but further requests should
be routed to the tenant farm at the load balancer level rather than at the application level.
While deploying this solution, you should also take care to achieve the following:
1. Prevent tenants from requesting resources when a tenant specific deployment is underway.
2. Retain tenants with high priority/ low latency SLAs in dedicated clusters so that they do not
face downtime while services for other clients are being deployed.
3. Segregate clients with lower priorities/ lower level SLAs into shared clusters where you can
utilize the scheduled downtime to run updates/ service deployments without facing SLA
penalties or customer dissatisfaction
4. Every tenant should have at least one backup server in the cluster to ensure availability.

8. Fig 5. A Load Balancer routing requests to a common server cluster versus an intelligent load balancer
routing to common, tenant specific clusters & Security service in SaaS

9. 6. Problem (Performance Throttling)
Business problem: How to design a „SaaS service‟ to provide client priority based servicing?
Technical cause: Caching at multiple levels is one of the best ways to improve application
performance, how to take advantage of application level caching with tenant priority? This problem not
only applies to caching but also to places where tenant priority based processing needs to be done.
Solution
Caching solutions range from a single JVM cache to a distributed cache to caches at other layers like
database etc. Best practices like setting the maximum cache size, expiry policy, etc… improve cache
and overall system performance.
In a SaaS application, it is always better to have flexibility to serve important tenants quickly. This
means that a caching solution or a service queue pattern has to include tenant priority in its processing
logic. For example, a cache solution should indicate the maximum cache size permitted for each
tenant and should be able to keep track of it, instead of just tracking the overall cache size at the
application level alone. It should have the ability to remove objects based on tenant priority
algorithms. A similar solution can be extended to service queues or other places where tenant priority
based processing is required.
Fig 6. Multi-level caching at the application level versus multi-level caching with tenant awareness to
control the tenant cache size and expiry logic in SaaS

10. 7. Problem (Error Handling)
Business Problem: How can client delight be improved by addressing client specific issues faster?
Technical cause: Error handling is very important to debug production problems; needless to
highlight its importance in a multitenant environment. Logging style of Distributed components &
different layers could differ. „Log time‟ is crucial in co-relating the logs to understand the big picture;
multiple time reference (machines/zones) adds another layer of complexity to this problem.
Solution
There is no single silver bullet that gives a readymade solution to all of the above stated challenges.
But careful selection of a few can address most problems:
1. Considering log as a “Separation of Concern” and using AOP for logging
2. Consolidating error handling in a single area using the “Fault Barrier” pattern
3. Using Asynchronous log mechanisms
4. Logging to a centralized place using a queuing mechanism
Distributed high performance low latency applications can log using a queuing mechanism. Depending
on the criticality of the logs, a memory buffering technique can be used to minimize IO operations, if
the downside of losing a few messages (rarely) is acceptable.
Fig 7. Application level logging to a common file versus tenant specific synchronous / asynchronous
logging using the Fault Barrier logging pattern in SaaS

11. Conclusion
To the technical community, SaaS is an IT service deployment methodology that is becoming
increasingly popular and which they need to understand and use to stay current. To ISVs, BSPs and
EHSPs, SaaS has the potential to open up an untapped market with significant revenue possibilities.
The SaaS business model, with its inherent cost advantages, may only be a few years old, but the core
concept of application resource sharing at various architectural levels has been with us for a long time.
It is just that recent technological advances have opened up new and economically viable ways of
addressing the problem of sharing resources.
Having said that, enterprises exploring the SaaS platform as a new/ alternative business channel should
also realize that the technical implementation framework is as important as the business model
supporting the venture. Ignoring the technical aspects of SaaS implementation is a sure way to facing
downstream business disruption issues.
This article is not intended to cover everything under SaaS Patterns, but intends to be one of the first
compilations of SaaS design patterns which, hopefully, will get critics, enthusiasts & supporters to
begin contributing to this discussion and help grow the knowledge base. Few other notable SaaS areas
which need problem-solution patterns are Identity Management, Security, Integration, Monetization,
Workflow and User Access Management.
References
[1] “
The State of Enterprise Software: 2009” Source: Forrester
http://www.microsoft.com/serviceproviders/saas/default.mspx
http://www.ddj.com/database/215900773;jsessionid=ZIPBUCLLD1JGSQSNDLRSKH0CJUNN2JVN?pgno=1
http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html
http://www.sqlmaestro.com/resources/all/row_level_security_mysql/