Storage and API Cost Optimization - Patterns
Learn more about Well-Architected Resource and Cost Optimization → Data Optimization
Patterns
| Where to look | What good looks like |
|---|---|
| Data Model Active Data | ✅ Active data receives premium storage treatment - Data accessed regularly for business operations remains in standard Salesforce objects with full query capability, workflow automation, and user access. Active data justifies storage investment because frequent access requires immediate availability ✅ Example: Current year opportunities and active cases remain in standard objects with full functionality |
| Data Model Warm Data | ✅ Warm data uses middle-ground storage strategy - Data accessed occasionally for reporting or reference may remain in Salesforce with archival flags enabling filtered views, or migrate to Big Objects supporting index-based retrieval without workflow capability ✅ Example: Prior year opportunities flagged as archived but remain queryable for historical analysis |
| Data Model Cold Data | ✅ Cold data archived to Big Objects or external systems - Data retained for compliance but rarely accessed moves to Big Objects (do not count against standard data storage limits) or external archival systems. Big Objects appropriate for high-volume archival with predictable access patterns. External archival to data warehouses or object storage provides lowest-cost retention for compliance data ✅ Example: Cases older than 36 months archived to Big Objects with index-based retrieval for compliance access |
| Data Model Expired Data | ✅ Expired data deleted through automated lifecycle processes - Data past retention requirements with no business value should be deleted through automated processes rather than accumulating indefinitely. Many organizations never delete data due to “what if we need it someday” concerns, resulting in storage growth consuming budget without business justification ✅ Example: Data retention policy automatically deletes records after 7 years based on regulatory retention requirements |
| Setup → System Overview → Data Storage Setup → Storage Usage | ✅ Pattern: Capacity dashboards show storage consumption by object with growth trends, API usage by integration with peak patterns, and processing capacity utilization with projections ✅ Enable proactive optimization before limits create outages or unexpected overage charges |
| No Storage Tracking → Annual Surprises | ⚠️ Anti-Pattern: Storage overage discovered during renewal negotiation requiring immediate purchase at premium pricing without time to evaluate archival strategies ⚠️ Organization purchases additional storage annually without analyzing what data consumes capacity or whether archival would reduce growth |
Patterns
| Where to look | What good looks like |
|---|---|
| Salesforce Files Large Files | ✅ External file storage integration for cost savings at scale - Store files in services like Amazon S3 or Azure Blob Storage with Salesforce maintaining reference records linking to external content. External storage costs $0.02-0.05 per GB monthly compared to Salesforce file storage at $1-3 per GB monthly depending on edition, creating 10-20x cost savings at scale ✅ Example: Contract management solution stores active contracts (last 24 months) in Salesforce Files for native preview and collaboration, automatically migrates older contracts to S3 with Salesforce links, reducing file storage 70% while maintaining access ✅ Trade-off: External storage integration requires development effort and introduces dependency on external service but delivers 10-20x cost savings for file-heavy use cases, breaking even within months |
| Content Management File Lifecycle | ✅ File lifecycle management archives or deletes old files - Implement automated archival moving files past retention thresholds to external storage or deletion. Files rarely accessed after initial creation including case attachments for closed cases and superseded document versions are primary archival candidates ✅ Note: File storage includes Salesforce Files, attachments, documents, and content. Organizations with document-heavy use cases including contract management, asset libraries, and case attachments frequently approach file storage limits faster than data storage |
Patterns
| Where to look | What good looks like |
|---|---|
| Sandbox Management Partial Copy Templates | ✅ Selective data templates optimize sandbox storage capacity - Exclude large-volume objects from Partial Copy templates when full data volume is unnecessary for testing scenarios. Implement sandbox-specific data retention removing records older than testing requires, freeing capacity for additional test data ✅ Example: Partial Copy sandbox template includes last 12 months of opportunities and cases but excludes archived data, providing representative testing data within 5 GB capacity rather than requiring Full Copy ✅ Trade-off: Defining selective data templates requires analysis effort but enables using lower-cost sandbox types by eliminating data unnecessary for testing scenarios |
| Sandbox Management Refresh Cadence | ✅ Refresh cadence aligned to actual data freshness requirements - Align sandbox refresh with actual data freshness requirements rather than arbitrary schedules. Many organizations refresh Full Copy sandboxes monthly when quarterly refresh would suffice for their testing patterns, wasting refresh capacity that could support additional sandboxes ✅ Example: Full Copy sandbox refreshed quarterly instead of monthly, freeing refresh capacity for additional Partial Copy sandboxes |
| Sandbox Management Temporary Sandboxes | ✅ Temporary sandbox management with expiration policies - Track environments created for specific projects or spike testing with documented deletion dates. Temporary sandbox proliferation is common source of waste as project sandboxes transition to permanent status without justification. Implement expiration policies requiring renewal justification to maintain temporary environments beyond initial scope ✅ Example: Project sandbox created with 90-day expiration requiring business justification to extend beyond project completion |
Patterns
| Where to look | What good looks like |
|---|---|
| Integration Monitoring Peak Usage Analysis | ✅ Peak usage analysis identifies scheduling optimization opportunities - Identify daily and weekly consumption patterns. Integration schedules concentrated during business hours compete with user-initiated API calls. Spreading batch integrations across off-peak windows optimizes capacity utilization without increasing limits ✅ Example: Batch integrations rescheduled from 9 AM to 2 AM, reducing peak-hour API contention and enabling additional integrations within existing capacity |
| Custom Code Bulk API 2.0 | ✅ Bulk API 2.0 for any operation processing hundreds of records - Use Bulk API 2.0 for any operation processing more than a few hundred records. Bulk API processes up to 150M records per job consuming minimal API calls compared to processing records individually ✅ Example: Nightly data synchronization uses Bulk API 2.0 processing 100,000 records with minimal API consumption instead of individual API calls per record |
| Custom Code Platform Cache | ✅ Platform Cache eliminates repetitive queries for reference data - Cache frequently accessed reference data to eliminate repetitive queries. Caching country codes, product catalogs, or configuration data reduces API consumption for integrations that repeatedly query unchanging reference data ✅ Example: Product catalog cached in Platform Cache, reducing API calls from 1,000 daily queries to single cache refresh |
| Integration Architecture Change Data Capture | ✅ Change Data Capture eliminates wasteful polling patterns - Use Change Data Capture for data synchronization rather than polling patterns. CDC publishes events only when data changes, eliminating wasted API calls checking for changes that have not occurred ✅ Example: Customer data synchronization uses Change Data Capture publishing events when customers update, consuming API calls only for actual changes (200 daily) rather than polling every customer record hourly (1.2M daily queries) ✅ Trade-off: Event-driven architecture requires Platform Events or CDC implementation effort but reduces API consumption 95%+ for change detection patterns, breaking even within weeks |
| No Monitoring → Reactive Discovery | ⚠️ Anti-Pattern: API consumption monitored only when limit exceptions occur, creating reactive firefighting and emergency architecture changes under pressure ⚠️ Missing proactive trend analysis enabling optimization before limits constrain business operations |
Patterns
| Where to look | What good looks like |
|---|---|
| Integration Pattern Synchronous Real-Time | ✅ Synchronous integrations consume highest API capacity - Real-time integrations consume one or more API calls per transaction. High-volume transaction flows can consume significant API capacity. Synchronous patterns appropriate when immediate data consistency is mandatory business requirement but carry highest API consumption cost ✅ Example: Order submission requires immediate inventory check and reservation in ERP system justifying synchronous pattern despite higher API cost |
| Integration Pattern Batch Processing | ✅ Batch integrations reduce API consumption 90%+ versus synchronous - Process records in bulk, dramatically reducing API calls per record. Bulk API 2.0 processes millions of records within minimal API consumption. Appropriate when near-real-time synchronization meets business needs and eliminates 90%+ of API consumption compared to synchronous patterns ✅ Example: Customer data synchronization runs hourly batch instead of real-time updates, reducing API consumption by 95% with acceptable 1-hour data latency |
| Integration Pattern Event-Driven | ✅ Event-driven patterns scale efficiently consuming resources only on actual changes - Use Platform Events or Change Data Capture for efficient event distribution without polling overhead. Event-driven patterns scale efficiently because they consume resources only when actual changes occur rather than checking repeatedly for changes that have not happened ✅ Example: Opportunity stage changes publish Platform Events consumed by downstream systems, eliminating polling and reducing API consumption by 98% |
| Integration Platform MuleSoft TCO | ✅ MuleSoft adds platform cost but may reduce total integration TCO - MuleSoft Anypoint Platform adds platform licensing cost ($20K-200K+ annually) but may reduce total integration TCO through intelligent caching, connection pooling, batch optimization, and unified governance across all integration patterns ✅ Trade-off: Middleware justifies investment when integration count exceeds 5-7 connections, providing reusability and governance that reduce long-term maintenance costs |
| Third-Party Integration API Pricing | ✅ Third-party API costs modeled based on projected transaction volumes - Model third-party costs based on projected transaction volumes reflecting actual usage rather than minimum tiers that assume low volumes. Third-party API pricing varies from free tiers through per-call metered billing to flat-rate enterprise licenses ✅ Example: Integration TCO model for payment gateway includes $15K annual platform fee + $0.10 per transaction estimated at 50K transactions annually ($5K) + $25K integration development + $5K annual maintenance for $50K total first year, $10K ongoing |
| Integration Maintenance Point-to-Point vs Hub | ✅ Point-to-point integrations multiply maintenance effort exponentially - Each integration point includes initial build, ongoing maintenance, error handling evolution, and adaptation when either endpoint changes. Point-to-point integrations multiply maintenance effort exponentially as system count grows. Five systems with point-to-point connections require 10 integration maintenance streams. Ten systems require 45 streams. Hub-and-spoke patterns through integration platforms reduce exponential growth to linear scaling ✅ Example: Organization with 8 connected systems transitions from 28 point-to-point integrations to 8 hub-and-spoke connections, reducing maintenance streams by 71% |
| Integration Operations Support Costs | ✅ Support and troubleshooting costs grow with integration count - Each integration creates potential failure points requiring monitoring infrastructure, alerting configuration, runbook documentation, and incident response capability. Include ongoing support costs in integration TCO beyond initial development ✅ Example: Integration support costs modeled at 15-20% of initial development cost annually for ongoing monitoring, troubleshooting, and incident response |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| All historical data remains in active storage indefinitely | ⚠️ Storage growth consuming budget without business justification. Organizations purchase additional storage annually without analyzing what data consumes capacity or whether archival strategies could reduce growth rate ⚠️ Remediation: Define data retention policy with lifecycle stages: active (0-12 months), warm (12-36 months), cold (36+ months archived), and expired (deleted after regulatory retention). Implement automated archival to Big Objects or external storage |
| Partial Copy template includes all objects without filtering | ⚠️ Consumes 5 GB capacity with historical data irrelevant to testing, forcing Full Copy purchase when strategic data selection would enable Partial Copy usage at significantly lower cost ⚠️ Remediation: Analyze testing requirements and create selective Partial Copy templates including only last 12-18 months of data and excluding large-volume objects unnecessary for testing scenarios |
| Integration polls all records every 15 minutes checking for changes | ⚠️ Consumes 5M API calls daily when 95% of polls find no changes, wasting API capacity on unnecessary queries. Creates risk of hitting API limits and preventing legitimate integrations from completing ⚠️ Remediation: Replace polling pattern with Change Data Capture or Platform Events that consume API calls only when actual changes occur, reducing API consumption by 95%+ |
| Integration makes separate API calls for each record type in sequence | ⚠️ Multiplies API consumption 5-10x compared to batching approaches. Order processing consuming 8 API calls per order when single composite call would suffice ⚠️ Remediation: Implement Composite API batching related operations into single API call, reducing consumption from 8 calls per transaction to 1 call per transaction (87% reduction) |
| Full Copy sandboxes purchased for every development team | ⚠️ Multiplies costs 5x when Partial Copy would meet most testing requirements. Full Copy costs 5-10x more than Partial Copy and refreshes only monthly versus every 5 days ⚠️ Remediation: Reserve Full Copy exclusively for pre-production UAT and performance validation. Use Developer Pro for development and Partial Copy with targeted data templates for integration testing |
| Integration approved based on “free API tier” without volume modeling | ⚠️ Projected transaction volumes exceed free tier in month 2, resulting in surprise $15K annual costs not included in budget or TCO analysis ⚠️ Remediation: Model third-party API costs based on projected transaction volumes including scaling projections. Include platform fees, per-transaction costs, and overage charges in integration TCO before approval |
| API consumption monitored only when limit exceptions occur | ⚠️ Creates reactive firefighting and emergency architecture changes under pressure. Limits create outages before optimization opportunities are identified ⚠️ Remediation: Implement proactive API monitoring dashboard with integration-level attribution, peak usage analysis, and growth projection. Set alerts at example utilization thresholds such as 70% and 85% providing lead time for optimization |
| Building custom document generation because “we have developers available” | ⚠️ Custom development at $80K initial build + $15K annual maintenance when AppExchange option at $15 per user monthly ($18K annually for 100 users) delivers faster deployment, vendor maintenance, and lower 5-year TCO ⚠️ Remediation: Evaluate AppExchange solutions before custom development for commodity capabilities. Model 3-5 year TCO comparing build versus buy including maintenance, platform compatibility, and support costs |
| Temporary project sandboxes transition to permanent status without justification | ⚠️ Sandbox proliferation consuming budget without business value. Organizations accumulate 20+ sandboxes when 10 would meet actual development needs with proper lifecycle management ⚠️ Remediation: Implement sandbox expiration policies requiring renewal justification. Track sandboxes with documented deletion dates and automated alerts for expiration review |
- Resource and Cost Optimization Pillar
- Resource and Cost Optimization - License Patterns
- Operational Excellence Pillar
Last Updated: 2026-06-08