What would you do differently when designing sharing for an org with tens of millions of records?

Volume changes the cost of every sharing decision, so I plan for recalculation as a first-class concern.

1. Treat OWD changes as a project, not a setting. Tightening an OWD on a large object triggers a full recalculation that can run for hours, during which access is inconsistent. It gets a maintenance window, a full-copy sandbox rehearsal to measure duration, and the compensating sharing rules prepared in advance.
2. Batch role and group membership changes rather than trickling them through, because each one invalidates portions of the sharing tables.
3. Use deferred sharing calculation for large loads and migrations. Salesforce Support enables it; you suspend recalculation, load, then resume and recalculate once.
4. Keep the role hierarchy as flat as the access requirements allow, since every level multiplies the share rows maintained.
5. Watch for skew proactively rather than discovering it through lock errors.
6. Sort bulk load batches by parent Id so concurrent batches do not contend for the same parent lock.

I would also budget for the fact that implicit sharing rows can dominate the tables, which means the recalculation cost is often larger than the configured rules alone suggest.