Best Practices for avoiding performance issue due to sharing rule

Every time you save a record, there are lots of actions being performed to determine who deserves access to it. Sharing rules, territory, and Apex code which takes time and resources. Also, when you make certain changes to a user, like changing their role, everything needs to be recalculated to see what the user does and does not have access to.

During this period, the record you are changing, as well as its parent and sibling records (records owned by the same parent) are locked. While records are locked, any other changes made to them are denied - resulting in an error. In a multi-user environment, this can quickly become a problem. Therefore, when defining a sharing model, the goal is to minimize the time it takes to calculate access. But how does one do that?

1. Avoid Ownership Skew (Avoid assigning one user too much ownership) – Skew refers to when non-uniform distribution happens. Ownership skew occurred when one user owns lots and lots of records on the same object, like an integration user creating lots of records without assigning them to a new owner or a customer can assign all of his or her unassigned leads to a dummy user. The rule of thumb is not to go over 10,000 records per user. If you must have ownership skew, then at the very least that user should be at the ‘top’ of the role hierarchy, so sharing does not roll up to other users. If it is not possible to prevent Ownership Skew, Salesforce recommends the following options
• Ensure that the user who owns a large number of records of the same object do not have a role, or the user is placed in a role without any hierarchy
• If organization-wide sharing of an object and visibility needs to be granted to additional users, it is best to grant access at the profile level.
• If profile level access is not possible to provide, then criteria-based sharing rule can be given to grant additional access in such cases.
2. Avoid Data Skew - Data skew primarily refers to a non-uniform distribution in a dataset. When a single parent record has many child records, such as having a dummy account to hold all your contacts. The same recommendation of 10,000 records per parent applies.
3. Whenever possible, use Public Read/Write org wide defaults. Sharing is essentially disabled for public objects - so the risk is entirely mitigated.
4. When making large changes, such as a big data import, mass changes to record ownership, role hierarchy, or redefining sharing rules, temporarily defer (pause) sharing. Enable them afterwards to recalculate all the changes.