Real-World Salesforce Caching: How Platform Cache Cut Execution Time in a Complex Commission Calculator
- Deepthi A
- Apr 27
- 2 min read
🎯 Why We Needed to Test Platform Cache for Real
After deeply exploring caching principles (see Part 1),we didn’t want to stop at theory.
We needed hard proof:✅ Real Apex logic.✅ Multi-object relationships.✅ Real performance numbers.
So we designed a complex Commission Calculator project — to measure exactly what Salesforce Platform Cache could (or couldn't) do.
🛠 The Business Problem We Simulated
We modeled a full-scale, real-world commission scenario:
Business Factor | Covered? |
Tiered commission rates | ✅ |
Regional variations | ✅ |
Seniority-based adjustments | ✅ |
Team performance bonuses | ✅ |
Active promotions and incentives | ✅ |
Currency exchange handling | ✅ |
The system had to crunch across six different custom objects — combining everything into a final Commission Statement.
No UI components. Pure backend Apex logic. Perfect for Platform Cache testing.
📦 Data Model Behind the Experiment
Object | Purpose |
Sales_Rep__c | Stores reps' regions, seniority, and metrics |
Team__c | Targets and performance tracking for sales teams |
Commission_Rules__c | Commission tiers based on product category and region |
Promotion__c | Active promotional bonuses |
Exchange_Rate__c | Currency exchange rates for accurate calculations |
Commission_Statement__c | Summary of commissions |
Commission_Detail__c | Line-item breakdowns |
📈 Execution Phases We Measured
We broke down execution into three clear phases:
Run Type | Description |
Uncached | Fresh SOQL for every operation. No caching at all. |
Cached (First Run) | Initial cache creation during run. |
Cached (Second Run) | Fully served from cache (no fresh SOQL). |
Each operation was timed precisely.
📊 Real Results — Operation Level Comparison
Operation | Uncached | Cached (First Run) | Cached (Second Run) |
getSalesRep | 17 ms | 8 ms | 7 ms |
getOpportunities | 27 ms | 23 ms | 23 ms |
getCommissionRules | 20 ms | 14 ms | 5 ms |
getPromotions | 16 ms | 9 ms | 4 ms |
getExchangeRates | 10 ms | 8 ms | 3 ms |
getTeamPerformance | 9 ms | 10 ms | 4 ms |
processCommission | 95 ms | 95 ms | 84 ms |
calculateCommission (total) | 194 ms | 167 ms | 130 ms |
🔥 Key Observations
✅ First Cached Run:Still involved some fresh SOQL (because we built the cache for first time).Noticeable but partial gains.
✅ Second Cached Run:Pure cache retrieval.Massive speedup — operations reduced to milliseconds.
✅ Operations like Promotions, Exchange Rates, Commission Rules moved from 20ms range to 0–5ms range.
✅ Overall execution time shrank by more than 30%.
✅ This is just for one Sales person, imaging the execution time improvements when you have a use case to process a batch
📚 Deeper Engineering Insights
1. Reference Data Must Always Be Cached
Promotions, Exchange Rates, and Commission Rules are perfect cache candidates: they don’t change minute-to-minute.
2. Session Cache Was Ideal
Caching inside the same user session gave us fast reuse without the complexity of Org-wide invalidation.
3. No Compromise on Accuracy
Business logic correctness stayed intact — caching didn’t change outcomes, only speed.
4. Governor Limits Are Protected
Fewer SOQLs → Lower risk of CPU/SOQL governor hits in bulk operations.
Comments