SFCC Platform Limits (Quota Survival Skill)
SFCC limits are not “edge cases”; they shape correct architecture. This skill is a pragmatic guide to:
- •Recognizing limit symptoms
- •Picking the correct workaround pattern
- •Avoiding designs that will fail under load
Quick Checklist
text
[ ] Identify your execution context (storefront controller vs hook vs job) [ ] Assume strict timeouts in hook/script contexts (design for the smallest budget) [ ] Keep external calls bounded; cache aggressively; avoid chatty integrations [ ] Never store large objects in session (store IDs; refetch/cache) [ ] Never write files from storefront requests (offload to jobs) [ ] Put retention policies on temporary custom objects from day one
Common Limits → Symptoms → Fix Patterns
| Symptom | Likely limit | Fix pattern |
|---|---|---|
| “ScriptingTimeoutError” / request abort | Storefront script timeout | Move heavy work to jobs; reduce synchronous work; fail fast on services |
| Generic 500 from OCAPI hook | Hook execution timeout | Keep hooks lightweight; move heavy logic to async processing or custom endpoint |
| “Too many HTTPClient calls” / enforced quota | Outbound call cap per request | Aggregate calls (BFF), cache, pre-load via feeds/jobs |
| Session data truncation / instability | Session size cap | Store identifiers only; use cache or refetch |
| Errors creating custom objects | CO quotas / create-per-request cap | Consolidate data; implement purge jobs; avoid COs for transactional logging |
| “Page size limit exceeded” | Rendered HTML size cap | Pagination, remote includes, lazy loading, move logic out of templates |
| Storefront fails when writing files | Storefront file I/O = 0 | Use job + WebDAV download pattern |
| SCAPI returns 429 | Rate limiting / load shedding | Honor Retry-After; exponential backoff; client-side caching |
Context Matters: Timeouts Differ
Design for the most restrictive context a script might run in.
- •Storefront controllers can have relatively generous execution budgets.
- •Hook/script contexts (OCAPI hooks, Page Designer scripts, etc.) can be much tighter.
Rule of thumb: if code could run in a hook, keep it hook-safe.
Integration Limits: External Calls Must Be Budgeted
Common failure mode: a page that makes many independent external calls.
Preferred architecture:
- •Aggregation layer (BFF/gateway): 1 call from SFCC, many calls downstream outside SFCC quotas
- •Aggressive caching for anything not truly real-time
- •Data feeds via jobs for data that can be slightly stale
Session: Treat It Like a Tiny Backpack
- •Store small primitives (IDs, flags), not full objects
- •Prefer
session.privacyfor user-specific temporary values that should clear on logout
Custom Objects: Treat Quotas as a Data Hygiene Contract
Anti-pattern: using custom objects as a high-volume event log.
Better:
- •Put integration/event logs in an external system of record
- •If you must store temporary records, define:
- •retention period
- •purge job
- •monitoring alerts
Storefront File I/O: The Asynchronous File Pattern
When you need a file (export/report) initiated by a shopper:
- •Storefront creates a “token” record (status = pending)
- •Job generates file into WebDAV (
/impex/src/...) - •UI polls a lightweight endpoint for status
- •UI offers download link once complete
- •Purge token + old files
Headless / Composable Notes
- •Expect HTTP 429; design the client to retry responsibly
- •Token churn can trigger SLAS limits; token caching + refresh flow correctness is mandatory
- •Managed runtime proxies can enforce hard request timeouts; long-running work must be async + poll
References
- •Rhino Inquisitor: The SFCC Quota Gauntlet (platform limits)
- •Salesforce Commerce API docs (timeouts troubleshooting)