CelloSaaS

Scalability Architecture

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

PrimarySecondary

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 ClientsSingle 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

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