Database Considerations for SaaS Products

Database
Architecture for
Software as a Service
ConFoo Vancouver 2016
Blog - shawnhooper.ca 
Twitter - @shawnhooper

Director of IT at  
Actionable.co
 
Web Developer for the past 20 years 
Happy to be visiting here from Ottawa
Hi, I’m Shawn

Centrally Hosted
Subscription Basis
Usually Accessed Through a Web Browser
What is SaaS ?

Learning & Development Platform (SaaS) 
Team conversations, individually-relevant actions, peer accountability
and real-time, applicable business insights.
Sold and supported through a network of professional consultants.
Actionable Conversations

* Team has an in-person conversation around a pain point 
* Each participant creates a commitment
* Participants “check-in” (1-10) on how they’re feeling about that
commitment 
* Assign an accountability buddy to encourage / keep them on track
* After a month the user, buddy, and manager “close the loop”.
* User, Manager and Consultant all get high-level insights.

Database Considerations

Users need to be able to sign up for your service
without the need for your manual involvement.
If you had to manually conﬁgure each client, this wouldn’t
exactly be “on demand”.
Self-Service

How does your database design handle tens, hundreds,
thousands, or millions (hey, I can dream!) of users?
Scalability

What impact does your architecture selection have
on the complexity of your code?  
 
(Application code, Database Queries, etc.)
Code Complexity

“With Great Power Comes Great Responsibility.”
How does your database design impact data security ?
Security

What impact does your architecture decision have on
your ability to make changes your application?
Extendability / Customization

* Multi Tenancy
* Single Tenancy
* Micro Service
Models We’ll Look At

Our tenants are companies.
Each tenant has many users.
Tenant

Multi-Tenant Model

All Users/Clients Share One Database
Multi-Tenancy Model

Multi-Tenancy Model

Self-Service: Easy - Just Add Database Records
Multi-Tenancy Model

Scalability: Limited by storage & system resources
Multi-Tenancy Model

Code Complexity: Queries need to include client ID
Multi-Tenancy Model

Code Complexity: Queries need to include client ID
Security Concerns: Poorly written queries, single point of data
breach.
Multi-Tenancy Model

Upgrades:
Easy! One copy of the database to perform migrations on.
Also means everyone gets upgraded at the same time.
Multi-Tenancy Model

Customization:
Extensions or custom features available to all clients.
Potential for more bugs to reach all users.
Multi-Tenancy Model

Data Storage:
All data lives in the same place.
This needs to be a consideration for where, geographically, you’ll
store your data.
Multi-Tenancy Model

“Oversight Accounts”:
For our resellers (consultants) and support staff, this model made it
easy to create dashboards that could look at the activity of many
tenants at the same time.
Multi-Tenancy Model

Single Tenant Model

Separate Database or Schema For Each Tenant
Single Tenant Model

Tenant 1 Tenant 2 Tenant 3

Self-Service:
More difﬁcult. Requires the system to be able to create a new
database schema or database when a user signs up for your service.
Single Tenant Model

Scalability:
Imbalance of server resources
Some users taking up more than their “share”
Single Tenant Model

Scalability:
This can be an advantage too. It gives you the ability to
move databases between servers to balance load.
You can even distribute based on geography for data storage.
Single Tenant Model

Security:
 
Data Separation! Excellent!
Single Tenant Model

Code Complexity:
 
No need to include Tenant ID in every query.
Instead, you need to manage connection strings.
Single Tenant Model

Upgrades:
 
In this model, you could upgrade some tenants and not others to do
a controlled release.
Single Tenant Model

Customizations:
 
You could fork and/or provide add-ons only available to some
tenants without an impact on other’s databases.
Single Tenant Model

Data Migrations:
 
A beneﬁt of this model is that you could easy backup/move one
tenant.
Example : Refresh Staging / Test Environment
Single Tenant Model

Oversight Accounts:
 
Not a great model for the “oversight accounts”.
Hard to build dashboards, aggregating data from
multiple databases.
Single Tenant Model

Micro Services Model

Databases Separated by Function

Authentication Products Transactions

This is much closer to the multi-tenant model we ﬁrst explored.

Self-Service:
You’re still just adding rows to tables, just in multiple databases.

Scalability:
Assign more/less resources to the services that need them the most.

Security:
You’ll be including the Tenant ID again.
However, less data is stored in each service, limiting
potential for loss in the event of a breach.

Code Complexity:
Multiple Database Connections to Maintain
(Multiple APIs too)

Code Complexity:
Lack of Referential Integrity between services.

Code Complexity:
Lots of trafﬁc between services!

Customization:
Bolting new features onto your application may be
adding a new micro-service.

We looked at:
* Multi Tenancy
* Single Tenancy
* Micro Service
Models We’ll Look At

So…. what’s the answer?

What did we do ?

Multi-Tenant Model
* Easy Scalability  
* Support for Oversight Accounts (Consultants / Resellers )
* Allowed users to be part of multiple tenants with one account
Downside:
We had to pick one geography in which
to store data.

Micro-Services Model
One service to handle the “Common” parts of the system:
User Accounts
Partner Proﬁles (Consultants)
Wholesale Pricing and Sales
Lists - ex: countries, industries, etc.

One service to handle the “Tenants” parts of the system:
Memberships
Conversations Run
Feedback & Check-Ins
Credit Usage / Purchase History

One service to handle the “Notiﬁcations” parts of the system:
E-Mail & SMS Message Schedules, Queues and Logs

One service to handle the “Content” parts of the system:
Why re-invent the wheel?
We used WordPress, connected with a REST API.

Hosting
RDS Instance with Amazon Web Services.
Allowed for scaling as the platform grows.

API
We built the application using API First methodology
using the Loopback Framework & Strongloop.

A new platform that allowed clients to
use the “Actionable” method to deliver
their own onboarding programs.
Duplicates the application & database
using the same Multi-Tenant Model
with only one tenant in it.
Actionable Training

shawn@actionable.co
Slides will be available shortly
at
shawnhooper.ca
Questions? Tweet @shawnhooper
Thank You!

Database Considerations for SaaS Products

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (14)

Similar to Database Considerations for SaaS Products

Similar to Database Considerations for SaaS Products (20)

More from Shawn Hooper

More from Shawn Hooper (13)

Recently uploaded

Recently uploaded (20)

Database Considerations for SaaS Products