Chapter 4. Data and Architecture Constraints
In this chapter we will dive deeper into the enterprise fit of the Salesforce architecture components. Some of the players in this space are open source offerings, some are third-party, and several are now owned by Salesforce. The products and companies discussed here should be taken as examples of the archetypes and not as recommendations. There are many valid options in each of these product industries. The important thing is to be aware of when scale factors might lead you to choose additional products outside of the Salesforce platform. Take another look at Figure 2-3 to review the basic definitions of resource types that are sold, provisioned, and used in a cloud service offering. The management of these resources will strongly influence your architecture. Figure 4-1 shows some of the areas that Salesforce architects expand into. In this chapter we will explore some of the reasons behind such expansions.
Figure 4-1. Large-scale data patterns
Complexity Boundaries
Working in Salesforce requires limiting the complexity of your data structures. Complex structures can have severe impacts on performance in any system. Salesforce has implemented many restrictions and limits to prevent unhealthy patterns. For example, if you have ever worked to tune query performance by avoiding full table scans and table locking, the best practices ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access