Cello saas scalability architecture

1. CelloSaaS
Scalability Architecture

2. 2
CelloSaaS : Scalability Architecture
Scalability in CelloSaaS
CelloSaaS can be scaled out either by scaling up or scaling out. Scale up is straightforward. Let us see
how the different layers of the celloSaaS application can be individually scaled out.
Production Deployment Architecture
User
Load Balancer
User User
Load Balancer
Active – Active
Cluster
Primary
Secondary
Caching
Caching
Cache Server
Farm
Web Server Farm
Application
Server Farm
Batch Processing
Server cluster-
VM
Single Database Server OR Partitioned Databases by modules and Clients
Single Hardware Single Hardware
Cache Layer: CelloSaaS supports Distributed cache such as AppFabric, Amazon elastic EC2. This ensures that
the cache layer can be scaled out by adding more nodes if there is a higher memory requirement for cache.
This also ensures that the cache is centralized and hence supports the web servers on scaled out scenario.
Database Layer: CelloSaaS supports vertical partitioning by modules as well as database Sharding by
Tenants.

3. 3
CelloSaaS : Scalability Architecture
Module Based Vertical Partitioning
Different modules can be modeled to reside on different servers based on the load. Data belonging to
modules is grouped to data groups. For examples in a HR system, the Core HR module and Leave
Management Modules can be grouped under “HR” Data group and Performance Management Data can be
grouped under “PMS” Data group. Each data group can reside in its own server. Example, “HR” Data group
can reside on Server 1 and “PMS” Data group can reside on server 2. During development the application
models the data as per data groups and passes the data group name while dealing with database operations
via cello DB APIs. Cello maps the data group to the location of the servers and connects respectively to the
right servers and fulfills the request.
Tenant Based Sharding
Even though an application data is vertically partitioned there might be a need to further scale out the data
within a single data group to multiple servers based on load. Cello supports this by providing the ability to
have data in multiple servers based on the tenant. In the above example let us assume the load on the PMS
data group is high and we want to further scale out the data of PMS to multiple servers. Cello supports this
by allowing each data group data to be sharded further by tenant identifier. As per cello each data group and
a tenant combination can reside in a server. While using Cello DB APIs cello automatically routes the tenant’s
requests to the respective server. For example
Tenant 1-n Tenant n+1 – 2n
PMS Server1 Server2
HR Server1
Web Layer - This is responsible for rendering the user interface. CelloSaaS advocates the following principle
to scale out this layer.
Session Usage - CelloSaaS does not use session for storing any data. If the application needs to store session
celloSaaS mandated out-of proc session storage. This ensure that the application is stateless and hence can
be easily scaled out
Cache Usage- CelloSaaS uses AppFabric distributed cache as the caching layer. This ensures that the memory
state of cache is centralized and hence the application becomes stateless which is necessary to be scaled out.
Application Layer- This is responsible for the web service driven business layer. CelloSaaS advocates the
following principle to scale out this layer
Per Call Services- All services are per call instances and hence can be scaled infinitely
Cache Usage- Application Layer also uses centralized caching mechanism of AppFabric which ensures that
the application layer is stateless and hence can be scaled out.
For more information: info@techcello.com, www.techcello.com