Content last updated January 2023.
Read about our update schedules here.

Introduction

Reliable solutions operate effectively and dependably. Reliable architectures are available when and where users expect, perform consistently, and scale with the business.

Reliability is a representation of system quality. A system that is not error-prone, behaves as expected, and provides results in a timely manner is highly reliable. Conversely, a system that takes too long to complete tasks (at least from a user’s point of view), doesn’t do what users expect, or “errors out” at critical times is not reliable. Because unreliable systems can’t be counted on to provide an accurate view of the information stakeholders need to make key business decisions, they undermine a system’s ability to be trusted.

The reliability of a system is not constant. A system that’s reliable today may become unreliable in the future if it hasn’t been designed to grow and evolve with your organization. This can lead to costly maintenance and the need to refactor or completely re-implement a system, using funds that could have been spent on more strategic projects.

You can improve reliability in your Salesforce solutions by focusing on three key habits: availability, performance, and scalability.

Availability

Availability is a measure of the percentage of time that your system is operational. The Salesforce Platform handles most infrastructure-level availability concerns for you. However, the availability of the solutions you build on the platform, and experienced by your customers, is a shared responsibility. It’s important to understand that even with Salesforce’s commitment to high availability, the risk of system downtime is never zero.

Architects must prepare for Salesforce system downtime, whether from events like planned maintenance windows or unforeseen circumstances. In addition to the risks of service disruptions, you need to consider how your solutions will maintain high performance and grow with the business. Architectural choices that focus too narrowly on current requirements can lead to availability issues over time.

Think about availability during the design phase, before your solution is built. Even a single incident can cause stakeholders to lose trust and doubt the overall value of a system. The longer you defer architecting for availability, the higher the actual cost of availability issues will be in the long run. As an architect, you will need to use the language of the business, framing technical concerns in ways that make sense to business stakeholders to drive buy-in and alignment around prioritizing availability work.

You can architect for higher availability for your Salesforce solutions through risk assessment and failure mitigation.

Risk Assessment

Assessing risks in the context of Salesforce architecture involves identifying potential hazards that could impact the operation of your system, users of your system (including employees, partners, and customers), and business processes. Often, the formal process of conducting risk analysis will fall under the responsibilities of project managers. As an architect, it is your responsibility to make sure any risk analysis adequately represents the concerns of both the technical and the business stakeholders relying on your solutions.

Some of the biggest pitfalls in risk assessment rise from simply not dedicating time and thought to the task. Far too often, teams skip risk assessment altogether. Or they conflate solving for backup and restore (an important part of mitigating risks to data integrity) with comprehensive risk assessment and mitigation.

To accurately assess risk for your Salesforce solutions, consider:

• Use a risk assessment framework. Some large enterprises may already have relevant risk matrices in place to assist you in structuring how hazards are to be classified, what kinds of information you need to gather, what you need to put in place for remediation, and more. If you don’t already have a risk assessment framework, find one from a reputable source and use it.
• Assess impact severity and risk categories using the perspective of your customers. Customer trust and perception are key to every business. In terms of business impact, risks that reach customers will most likely outweigh risks that don’t. Customers may not think about or perceive risks in the same way as internal teams. If a customer can’t log in to their account, they are unlikely to care about the root cause. They care most about their own, immediate experience.
• Prioritize your risks. Ideally, every risk will be linked to a solid mitigation and response plan. In reality, you will have gaps that you need to address over time. This is where adopting a “deliver value early and iterate” approach is important. You and your delivery and maintenance teams can only address so much work at a given time. At Salesforce, a common expression is: If everything is important, nothing is important. We use V2MOMs to prioritize and focus work across the entire company, throughout teams, and even down to the level of each individual. (You can learn more about V2MOMs on Trailhead.) Use your risk assessments as a chance to work with stakeholders on prioritizing and committing to the most important work to be done.

The list of patterns and anti-patterns below shows what proper (and poor) risk assessment looks like within a Salesforce solution. You can use these to validate your designs before you build, or identify areas of your system that need to be refactored.

To learn more about Salesforce tools related to risk assessment, see Tools Relevant to Reliable.

Failure Mitigation

A failure point is any place in the system that can cause significant parts of your system to perform unexpectedly (or not at all) when a service disruption or problem occurs. In reality, almost any point in a system could turn into a failure point. Good mitigation isn’t about attempting to pinpoint every potential failure point in a system. It is instead establishing ways to quickly and accurately classify and prioritize failure points and responses to allow maintenance and support teams to respond effectively. (For more on this, see incident response.)

To develop better failure mitigation strategies, consider:

• Classify triggers in terms of people, process, and technology. As you categorize risks in terms of people, process, and technology, apply this same thinking to how high-priority failure points could be triggered. This approach will help with both identifying potential failure triggers, and organizing how you develop responses. Seemingly divergent failure triggers have similar mitigation approaches, based on their trigger classification.

• Identify what basic, intermediate, and mature mitigation look like. It will take time to build out mitigation strategies. Defining different levels will help you and your team see where you can put controls in place immediately, and how to focus your efforts over time. Always look for opportunities to use automation in your mitigation approaches — as early as is feasible. To illustrate what this looks like in practice, the following example shows a people-oriented trigger, and what policy-based mitigation looks like at basic, intermediate, and mature levels.

The list of patterns and anti-patterns below shows what proper (and poor) failure mitigation looks like within a Salesforce solution. You can use these to validate your designs before you build, or identify places in your system that need to be refactored.

To learn more about tools available from Salesforce for failure mitigation, see Tools Relevant to Reliable.

Availability Patterns and Anti-Patterns

The following table outlines patterns to look for in your Salesforce operations and anti-patterns to avoid or target for remediation.

Performance

Performance, in the context of system architecture, is a measure of a system’s overall processing capacity (throughput) and how fast it responds to requests and demands (latency). Typically, you derive an understanding about how your system performs through testing and production monitoring. A performant system completes processes within a timely manner, at any anticipated level of demand.

Poor performance goes hand-in-hand with higher latencies and lower throughputs, which lead to lower productivity and increased user frustration. Further, performance issues are often a matter of some urgency, and can lead to loss of trust among customers as well as financial losses.

You can improve the performance of your solutions by optimizing throughput and optimizing latency.

Note: Throughput and latency optimizations are essential aspects of improving system processing and responsiveness. It’s important to remember, however, that overall system performance also depends on how well you architect for scale. You must consider both dimensions in your designs.

Throughput Optimization

In terms of Salesforce architecture, throughput is the number of concurrent requests a system can complete within a given time interval. Salesforce solutions that have been designed and optimized for throughput better operate within the built-in governor limits of the platform.

Optimizing throughput in Salesforce begins with accurately calculating workloads in your system and planning for growth. Without accurate projections for how what kinds of demands will be made on the system, you will be unable to pinpoint potential issues with the throughput capabilities of your system. There are three dimensions to consider when thinking about workloads:

• the number of transactions your system needs to process within a given amount of time
• the number users who need to access your system simultaneously
• the overall complexity of transaction logic in the system

When thinking about performance, there can be a tendency to focus too narrowly on compute and the constraints on maximum CPU time that are among the platform’s governor limits. Teams that maintain this narrow focus overlook many methods for optimizing throughput that are unrelated to raw processing power. By expanding your view and applying these methods (outlined below), you can improve the overall throughput and efficiency of your Salesforce architectures, which in turn will help reduce latency and increase overall system performance.

To optimize throughput in your system, consider:

• Favor asynchronous processing. The Salesforce Platform uses transaction contexts to control for data integrity and limit the potential for runaway code to dominate compute resources. (For more on this topic, see transactions in Architecture Basics.) For this reason, using asynchronous (async) processing where possible can help minimize potential bottlenecks in synchronous execution contexts. (For more on designing transactions, see transaction handling.) Using async compute is not a cure for every kind of performance issue, and you’ll need to take latency into consideration when incorporating async processes. Certain platform capabilities, such as queueable Apex, may increase latency during traffic spikes because messages wait longer in a queue. Depending on the use case, you may decide to tolerate a potential decrease in responsiveness, in order to maintain (or improve) throughput. In other cases, increased latency may not be acceptable.
• Always use bulkification. Bulkification, at a high level, means carrying out operations against collections. Often, discussions of bulkification for Salesforce focus on streamlining data operations against collections. (For more on this, see Planning for Scale). However, bulkification at a system level involves more than just data operations. Tasks like callouts or complex computations should also be considered candidates for bulkification. A principal benefit of proper bulkification is that it reduces overhead by enabling multiple operations to be executed with one request, rather than executing a single request per operation. (For more on this topic, see Bulk Operations).
• Use SOSL for searches and treat SOQL like a data operation. It may seem obvious that using overly complex SOQL statements will increase the amount of time it takes the system to retrieve records. Less obvious, however, is the fact that even using SOQL adds overhead to the underlying relational database that slows down processing. Especially if using text or wildcard criteria, locating records via SOSL will be more performant and efficient because it uses the platform’s search engine, which is optimized for full-text indexing and universal searches. To optimize record retrieval patterns, ensure your design standards specify when to use SOSL to find data in your system, and how to use SOQL for efficient data operations. (For more on this, see Planning for Scale).
• Use Platform Cache. The Lightning Platform Cache layer provides faster performance and better reliability when caching Salesforce session and org data. Platform Cache improves performance by distributing cache space so that some applications or operations don’t steal capacity from others.

The list of patterns and anti-patterns below shows what proper (and poor) throughput optimization looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further optimization.

To learn more about Salesforce tools for throughput optimization, see Tools Relevant to Reliable.

Latency Optimization

Latency is a measure of how fast a system completes an execution path. Optimizing the throughput of your system will contribute to improving latency. Another dimension of latency is perceived performance, or how responsive the system seems to a user.

People don’t want to wait for pages to load or processes to finish. Users of your system will become frustrated if they frequently experience lengthy load times when trying to navigate list views, record pages, reports, and so. When this happens, customers or partners may decide to take their business elsewhere rather than deal with poorly performing systems. Internally, employees may create workarounds to avoid using the system as designed — which can create downstream issues for security and data integrity.

Perceived performance can be difficult to diagnose. When a user reports a slowness issue, support teams may be unable to reproduce the issue because increased latency is often due to a combination of smaller issues that build upon each other. This can make it difficult to diagnose the exact cause of perceived performance issues.

To reduce latency and improve responsiveness in your Salesforce system, consider:

• Optimize reports. Ensure each report serves a single, specific purpose. Clearly identify the audience and purpose of every report in your system. In reports, include only the minimum amount of data that audience members need to make decisions. Removing columns that don’t align to a report’s purpose will improve report performance by reducing the amount of data that needs to be retrieved and displayed.
• Optimize filters. Effective filters speed up report and list view performance by accurately scoping the number of rows that are retrieved from the database. As a general rule, the more specific you make your filter logic, the more efficient the underlying query for data will be. Ways to optimize filters include:
  • Use equals/not equal instead of contains/does not contain
  • Avoid filtering by formula fields
• Simplify your sharing model. An overly complex sharing model can slow down a variety of processes, because the system has to check the sharing and visibility model to determine if a user has access to the data to be displayed or processed. Complex sharing calculations can increase latency in reporting, list views, and automations running in user context. For more on how to improve sharing models, see Sharing and Visibility.
• Optimize custom UI components. Custom-built user interface (UI) components can increase latency. To optimize performance in custom UI components, consider:
  • Use Lightning Web Components (LWC). The LWC framework is closely aligned to modern web standards. Custom components written in LWC will render more efficiently in web browsers and enable developers to use more performant JavaScript methods. Always prefer LWC to older UI technologies, such as Aura or Visualforce.
  • Use Lightning Data Service. Lightning Data Service handles the creation and maintenance of secure, performant, and shared caching across components. Use it to avoid unnecessary round-trips to the server for data — and increase overall application responsiveness.
  • Use client-side sorting and filtering for list data. For both LWC (preferred) and Aura components, developers can use standard JavaScript array functionality to sort, filter, and select values on the client side, reducing the number of required trips to the server.

The list of patterns and anti-patterns below shows what proper (and poor) latency optimization looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further optimization.

To learn more about Salesforce tools for latency optimization, see Tools Relevant to Reliable.

Performance Patterns and Anti-Patterns

The following table outlines patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

Scalability

Scalability is a measure of a system’s ability to continue to perform over time as it evolves and grows. A system that is scalable is able to handle large increases in transaction volumes or concurrent access without requiring foundational changes. Salesforce’s platform services are designed to support application scalability (for more on this, see Internal Platform Processing). With that said, as your organization grows and demand for your products and services increase, you are responsible for creating a system that can perform effectively (and as expected) as demands on the system and data volumes increase. Architecting for scalability from the start will result in faster delivery timelines for new features and less downtime as users and traffic increases.

Sometimes, a business will reach a critical “tipping point” where a system’s original design can no longer support the current degree of scale, and unexpected events send the system into an unstable state. Systems that have not been designed for scalability require constant troubleshooting, redesign, and refactoring — often at great cost to the business. Scalability issues commonly compound over time, creating multiple performance degradations throughout a system. In some cases, businesses find themselves spending a majority of development and maintenance resources on addressing scalability issues, instead of new features that create value.

You can better architect for scale by focusing on three keys: data model optimization, data volume management, and scale testing.

Data Model Optimization

Data model optimization involves structuring the objects in your org (and relating them to one another) in a way that enables your users and automated processes to retrieve the data they need as quickly as possible. Taking steps to improve throughput will address many performance issues, but your efforts won’t be as effective without an optimized data model.

The negative impacts of a poorly designed data model are not immediately noticeable; rather, the weaknesses are exposed as the system grows in terms of data volume, processes, users, and integrations. A well-designed data model design makes it easier to continuously refactor your application as requirements are added and extended.

To optimize your data model, consider:

• Use the prebuilt data models from Salesforce. Salesforce provides prebuilt data models for Sales, Service, and a variety of industry verticals. Using the data models provided by Salesforce ensures capabilities in your system are defined only once (eliminating redundancy and silos), establishes a single source of truth across the entire system, makes it easier to understand application data with analytics, makes it easier to use Salesforce’s prebuilt artificial intelligence services, lowers maintenance costs (by reducing customizations you need to support), and reduces technical debt.
• Choose the right data types. Understand the different types of fields supported by Salesforce and the limitations of each. Consider reporting and encryption requirements so you can avoid the need to convert data between types in the future.
• Choose the right relationships. Salesforce supports two kinds of relationships between objects: master-detail and lookup. Master-detail relationships offer two primary benefits: built-in rollup summary capabilities (to count and aggregate detail from child records) and built-in cascade deletion capability (deleting a parent can also delete child records). However, make sure you understand the sharing and data skew implications of master-detail relationships before deciding to use them.
• Denormalize for scale. Normalization is the process of structuring your data model to optimize for reduced data redundancy and improved data integrity, but it can lead to scale issues. Denormalized tables can be more performant at scale, but data integrity and redundancy will need to be considered.

The list of patterns and anti-patterns below shows what proper (and poor) data model optimization looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further optimization.

To learn more about Salesforce tools for data model optimization, see Tools Relevant to Reliable.

Data Volume Management

Data volume is a measure of the amount of data stored within your system, based on record counts and sizes. If your org has tens of thousands of users, tens of millions of records, or hundreds of gigabytes of total record storage, you have a large data volume. The volume of data and relationships between objects in your org will affect scalability and will likely have a greater impact on scalability than the number of records alone.

To improve the scalability of orgs with large data volumes, consider:

• Distribute child records. Avoid parent-child data skew by ensuring that no parent has a large amount of child records. The general recommendation is no parent should have more than 10,000 child records. For example, in a deployment that has many Contacts but does not use Accounts, consider setting up several Accounts records and distributing related Contact records among them.
• Distribute ownership of records. Avoid ownership skew by ensuring no single user or queue (or all the members of a single role or public group) owns more than 10,000 records from the same object. “Parking” data with a “dummy user” is a practice that often leads to ownership skew. If you encounter this issue, be mindful of the impact this will have on sharing calculations. If you cannot redistribute records to relieve the ownership skew, avoid assigning the data-owning user to a role. If the org sharing model requires a role assignment, place the data-owning user in a distinct role at the top of the sharing hierarchy. Do not allow for frequent or unplanned changes in that user’s role, as any changes will have significant performance impacts due to sharing recalculations. Keep that user out of public groups that could be referenced in any sharing rules.
• Reduce the amount of record data in Salesforce. Salesforce is designed to provide business with a single view of the customer. It can seem counterintuitive that limiting data in Salesforce could be a best practice. However, the power of that single view lies in how well it enables business users to understand and take action on customer data. As volume grows, data that is not current and not relevant to day-to-day processes or analytics lead to several issues, including degraded app performance, increased data security risk, and negative impacts on search, reporting, and analytics. To avoid such issues, define a data lifecycle for every object in your data model, with timelines and classifications for data as it ages and loses immediate business value. In accordance with this data lifecycle, implement procedures to manage data over time, including:
  • Data archiving and purging. Take steps to remove records that are no longer needed by the business to help keep data volumes as low as possible. Use the Bulk API 2.0’s hard delete function to delete large data volumes.
  • Data aggregation. Create aggregation custom objects that summarize key historical trend or summary data in a format compatible with reporting. Populate the custom objects using batch Apex. Users can then execute reports based on the aggregated object records.
  • Data tiering. Maintain large data sets in a different application when the data is no longer needed for Salesforce reports or day-to-day work. Make the data available in Salesforce as needed via mashups, callouts, or external objects.

In practice, you may not always be able to immediately address the root cause of a scalability issue when problems arise. For this reason, Salesforce does provide options to help ease immediate pain points. It is important to know that enabling these features in your org is not a viable, long-term architectural strategy for dealing with large data volumes. These short-term, stopgap workarounds can help reduce latency in systems suffering from poor data architecture, but they can also add technical debt to your org.

Short-term workarounds for scale issues include:

• Custom indexes. Indexes are stored in a special internal table that the platform’s query optimizer uses to speed up data access operations (for more on this, see Multitenant Indexes). The platform automatically indexes certain types of fields by default. To speed up poor-performing queries, you can request additional custom indexes by contacting Salesforce Customer Support. Use the Query Plan tool to determine whether custom indexes will improve the performance of your queries.
• Skinny tables. If you need to further optimize queries for common sets of fields on objects with more than 1 million records, skinny tables can help. Skinny tables eliminate the background join that occurs when using custom and standard fields in a report or automation. Skinny tables must be enabled by Salesforce Customer Support.

The list of patterns and anti-patterns below shows what proper (and poor) data volume management looks like in a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further optimization.

To learn more about Salesforce tools for managing data volumes, see Tools Relevant to Reliable.

Scale Testing

Scale testing is a specific area within performance testing. Performance testing overall is concerned with how well an application or system holds up under a variety of conditions — including differing levels of demand. If your Salesforce system handles B2C-scale applications, has a large volume of users, or has large volumes of record data, ensure you incorporate performance and scale testing into your application lifecycle management (ALM) process.

To maximize the benefits of performance and scale testing, make it an integral, intentional part of your quality assurance processes at a reasonably early stage in the development cycle. (For a more in-depth look at Salesforce testing and recommendations for structuring test cycles, see Testing Strategy.)

To create effective scale tests for Salesforce, consider:

• Know which tests matter. You will likely have a fixed amount of time to conduct your scale or performance testing, making it impractical to test every facet of your system. Not all features are used equally, and not all scale bottlenecks will impact the business equally. Ensure your scale tests are focused on the most highly used and highly valued parts of the system. Define and understand the most important opportunities for verifying and improving scale and performance in your org.
• Know what “good enough” looks like. Defining the success criteria for your scale and performance tests is critical. You and your development teams will use these as testing benchmarks, and you should also ensure they inform the functional requirements development teams build towards in the first place. Typically these criteria include supporting a specific number of concurrent users with response times less than an agreed upon value, and your SLOs. Define your key target criteria, and design scale and performance tests that ensure the criteria are met.
• Ensure you have adequate environments to scale test. Scale testing requires environments that are representative of production. The data sets, request demographics, request rates, and workload characteristics should all match what you see in production as much as possible. Salesforce offers sandbox environments for development and testing, with different capacities to support data sets copied from production. You must use a Full sandbox for scale testing. If your org doesn’t have a Full sandbox available for scale testing, you will not be able to run adequate scale tests.

For more in-depth guidance on how to conduct scale and performance testing, see How to Scale Test and 7 Anti-Patterns in Performance and Scale Testing on the Salesforce Architect blog.

The list of patterns and anti-patterns below shows what proper (and poor) scale testing looks like for a Salesforce org. You can use these to validate your designs before you build, or identify opportunities for further optimization.

To learn more about Salesforce tools for scale testing, see Tools Relevant to Reliable.

Scalability Patterns and Anti-Patterns

The following table outlines patterns to look for (or build) in your org, and anti-patterns to avoid or target for remediation.

Tools Relevant to Reliable

Resources Relevant to Reliable

Tell us what you think

Help us keep Salesforce Well-Architected relevant to you; take our survey to provide feedback on this content and tell us what you’d like to see next.