This month is a technical deep dive, with no apologies! The biggest challenge faced by service providers when scaling their systems isn’t voice traffic volume but data scaling. Imagine you are a service provider delivering service to 1000 contact center agents across 20 to 50 tenants and all of these tenants host their data on your database servers. It’s not unusual for some tenants set up inventory management rules that result in the database getting a battering while others define huge schemas and then never do any housekeeping. The list of things that a tenant can do to break a hosted database server is endless!
Running a relational database on a virtual machine (VM) is far from good. Trying to provision a database server VM instance per tenant with the right dimensions is great in theory but bad in practice. Relational databases are optimised for direct file system access. Of course, you can have a VM map directly on to a dedicated disk, but what happens when 20 small tenants each have to have their own disk? Not a practical option.
So that leaves the option of partitioning the database server; running multiple instances of your database server on one host, or multiple schemas, depending on how your database management system does partitioning. Once you have a handle on database partitioning and resource allocation there is then the issue of throughput management.
Your contact center database services ideally need to run a database proxy, in order to serialise database access for high throughput. Remember the days when each agent client would attempt to do a query to find a customer record? 250 client connections making random access lookups against the same table – not good! So, instead, you have an architecture where the database proxy caches customer records to serve up to clients, but also mediates any database lookup requests and pipelines these to the database along with other transactions.
This sort of architecture can deliver huge throughput. However, try doing this for a 1000 agent hosting platform and at some point either the database server(s) will fry or the database proxy service(s) will break as the native database driver struggles to cope. Solving this problem requires a certain amount of cleverness on the part of your technology supplier.
There are 2 aspects to this:
1) In the event that the database is cooked and is temporarily offline, the database proxy must be able to cache transactions and perform roll-forward recovery, or deal with permanent failure gracefully.
2) In the event that the database driver (hosted in-process by the proxy) is cooked, the proxy must be architected in such a way as to be able to recover from a database driver crash without loss of data.
The message is simple; you need to make sure your technology provider has solutions to both these problems if you want to be successful in delivering large-scale contact center hosting.
