Salesforce offers a gigantic database-as-a-service platform to millions of customers worldwide. It shouldn’t be that hard to imagine that it handles a lot of data per hour. Their teams actually work on volumes of data from 10 million records onwards.
As the popularity of Salesforce has skyrocketed so has the size of the databases the company employs. More customers come in, so the databases continue to grow.
Handling Huge Volumes of Data
Salesforce as a company has stacked up on experience handling large data volumes. They have formulated a lot of best practices when it comes to data management.
When bulk data load slows down they can approach the issue using three approaches. First, Bulk API is used. Another solution is to disable the preload of work flow rules, validations, and triggers. Another practice is to transform and cleanse the data preload.
That is just an example of how large data volumes are handled on Salesforce. Of course other best practices are more challenging than others.
Managing Databases
Everything goes through a database, speaking from a software perspective. The primary data flows between the database tier and the core app server. However, since Salesforce is heavily driven by a database system, it is paramount to reduce the load on the database tier or the entire system.
Then comes their API Cursor Server, which improves the performance of the core database. ACS is actually a pair of servers that provide offload cursor processing.
Salesforce maintains a pool of servers to handle the massive traffic load they get from daily operations. A handful of these servers deal with login requests while others manage the users’ sessions.
API traffic is another source of the huge load on the entire system. 60% of the traffic that goes to the application tier comes from APIs. Depending on the request and needs of users, they will be redirected to several server tiers.
For instance, the core app tiers employ 10 to 40 app servers. To manage asynchronous processes, Salesforce employ content batch servers and content search servers. The bulk of the strategy, as can be observed, is to reduce the load on the database tier of the system.