The Hitchhiker’s Guide to Telco Transformation - Part 9
Scaling Considerations in Your Multi-Tenant Design
In the last 2 blogs of this series, I discussed the different architectural approaches to multi-tenant applications, as well as their pros and cons. More specifically, I dove into the variety of considerations which must be taken into account when choosing the approach that is right for you. We discussed: cost considerations, security considerations, tenant considerations, encryption considerations, and last, but not least, scalability considerations.
Scalability is an important topic that deserves its own blog post (in my opinion). I will tackle it here, in my last Hitchhikers Guide.
Database Scaling Considerations
The two main tools to use when scaling out a database out are replication and partitioning. Replication involves copying all or part of a database to another location, and then keeping the copy or copies synchronized with the original. There are two options for replication: Single master replication, in which only the original can be written to, is much easier to manage than multi‐master replication, in which some or all of the copies can be written to and some kind of synchronization mechanism is used to reconcile changes between different copies of the data.
You can partition a database by relocating whole tables, or by splitting one or more tables up into smaller tables horizontally or vertically. Horizontal partitioning means that the database is divided into two or more smaller databases using the same schema and structure, but with fewer rows in each table. Vertical partitioning means that one or more individual tables are divided into smaller tables with the same number of rows, but with each table containing a subset of the columns from the original. Replication and partitioning are often used in combination with one another when scaling databases.
Tenant‐Based Horizontal Partitioning Consideration
A shared database should be scaled out when it can no longer meet required performance KPI. For example, when too many users are trying to access the database concurrently or the size of the database is causing queries and updates to take too long to execute. Or when operational maintenance tasks start to affect availability.
The simplest way to scale out a shared database is through horizontal ﴾row‐based﴿ partitioning based on tenant ID. SaaS shared databases are well‐suited to horizontal partitioning because each tenant has his own set of data, so you can easily target individual tenant data and move it. However, don't assume that if you have 100 tenants and want to make 5 partitions you can simply separate 20 tenants at a time and move them. Different tenants can place radically different demands on an application, and it's important to plan carefully to avoid simply creating smaller, but still overtaxed, partitions while other partitions go underused.
If you're experiencing application performance problems because too many end users are accessing the database concurrently, consider partitioning the database to equalize the total number of active end‐user accounts on each server. If you're experiencing problems relating to the size of the database, such as the length of time it takes to perform queries, a more effective partition might be to target database size instead, assigning tenants to database servers in such a way as to roughly equalize the amount of data on each one.
The partitioning method you choose can have a significant impact on application development. Whichever method you choose, it's important that you can accurately analyze and report on whatever metrics you intend to use to make partitioning decisions. Building in reporting capabilities will let you better monitor your application and better understand usage patterns and needs.
It’s likely that you'll need to repartition your data periodically, as your tenants evolve and change the way they work. Choose a partitioning strategy that you can execute when needed without unduly affecting production systems.
Single Tenant Scale-Out Consideration
If some or all tenants store and use a large amount of data, tenant databases may grow large enough to justify devoting an entire server to a single database that serves a single tenant. The scalability challenges in this scenario are similar to those facing architects of traditional single‐tenant applications.
With a large database on a dedicated server, scaling up is the easiest way to accommodate continued growth. If the database continues to grow, eventually it will no longer be cost‐effective to move it to a more powerful server, and you will have to scale out by partitioning the database on to one or more additional servers. Scaling out a dedicated database is different than scaling out a shared one. With a shared database, the most effective method of scaling involves moving entire sets of tenant data from one database to another, so the nature of the data model that you use isn't particularly relevant. When scaling out a database that's dedicated to a single tenant, it becomes necessary to analyze the kinds of data that are being stored to determine the best approach.
This brings to the end my series on telco transformation. I hope you found it helpful and interesting. See you soon in my new series….