In the previous article, we provided an overview of the underlying architecture of the Salesforce platform. Today, we’ll delve deeper into the intricacies of the platform’s data layer, examining how Salesforce maintains and manages data in the cloud.
Salesforce’s Multi-Tenant Architecture
Salesforce is built on a multi-tenant architecture, which means that all users and applications share a common infrastructure and code base. When you create or customize an application within Salesforce, the platform stores related metadata in shared database tables. These tables store metadata for all tenants (or ‘orgs’) within the platform.
There are special tables that store metadata about the objects that you define for an application and separate ones that store metadata about the fields you associate with each object. Salesforce uses metadata caches to retain the most recently used metadata in memory, thereby improving response times and reducing the amount of disk IO.
Understanding Universal Data Dictionary
Salesforce has innovatively harnessed the power of a concept called the Universal Data Dictionary to revolutionize how data is managed and maintained. Instead of relying on traditional database structures where objects, stored procedures, and triggers are fixed and hard-coded, Salesforce’s model leans on virtual constructs. These constructs are not directly built into the system but are described using detailed metadata. This metadata approach provides an abstraction layer, offering immense flexibility and adaptability.
The beauty of this approach is its simplicity and centralized nature. All this descriptive metadata, which dictates the behaviour and structure of tenant-specific applications, is stored within a select number of database tables. These tables collectively form what is known as the Universal Data Dictionary. This centralized system ensures that Salesforce can efficiently manage, update, and scale its services across multiple tenants without causing interference or overlap. Moreover, it allows for streamlined schema maintenance, rapid deployment of new features, and a high degree of customization for each tenant, all while maintaining the system’s robustness and reliability.
Shared Table for Application Data
When you use an application to read or write data, Salesforce stores your data in a shared table that maintains data for all tenants. This system table stores the application-accessible data, mapping it to all the org-specific tables and their fields.
Each row in this table includes identifying fields such as a globally unique identifier (GUID), the ID of the org that owns the row, and the encompassing object identifier. Moreover, the value columns (or Flex columns) store application data that maps to the objects and fields defined in the metadata tables.
Schema Maintenance
Given that the system allows for object and field definitions as metadata instead of individual database structures, Salesforce can allow for schema maintenance activities in one org without affecting others. This innovative approach facilitates seamless updates and customizations without disrupting the workflow of other tenants. Interestingly, this model’s versatility is further showcased by its capacity to handle unique data types, such as Character Large Objects (CLOBs), which can store long text fields of up to 32,000 characters. Thus, while the primary advantage of Salesforce’s metadata-driven architecture is ease of maintenance, it also demonstrates adaptability in catering to diverse data requirements.
Internal Metadata and Performance Optimization
The Salesforce platform also maintains internal metadata in a number of tables that the kernel uses to optimize request latency at runtime. This includes indexes and relationships between objects that help enhance performance and efficiency. These tables aren’t just passive repositories; they play a proactive role in the system’s functioning, particularly when it comes to ensuring optimal performance.
For a platform as robust as Salesforce, quick and efficient data retrieval is crucial. This is where the aforementioned metadata tables become instrumental. They hold essential information about indexes associated with the platform’s data. Just as the index in a book helps readers quickly locate specific information, these digital indexes enable rapid and precise data access, minimizing the time spent on data retrieval processes.
In addition to indexes, the metadata tables also contain invaluable information about relationships between different objects. Understanding these relationships is pivotal. For instance, if one object is related to another, knowing this relationship can guide the system to make intelligent decisions about data fetching, thus reducing unnecessary operations. These relationships act as a map, guiding the system to traverse the vast data landscape efficiently.
In essence, these internal metadata tables are the unsung heroes behind Salesforce’s impressive performance. They work silently in the background, ensuring that every user request is processed with minimal latency and maximum efficiency, resulting in a smoother and more responsive user experience.
Takeaways for Architects
The architectural concepts described here may not be things you can directly manipulate as an architect. However, having a deep understanding of these aspects will inform your decision-making and add clarity to your architectural choices within the Salesforce platform.
Explore More
This article only scratches the surface of Salesforce’s multi-tenant data architecture. To learn more, the “Platform Multi-Tenant Architecture” document, available on the Salesforce Architects website, is a great resource. Also, check out the Well-Architected Framework for best practices and principles.
Stay tuned for our next exploration into Salesforce architecture. Make sure to follow us for more insights and deep-dives into the ever-evolving world of Salesforce.
