SFCC Platform Limits: A Tech Lead's Survival Guide

Salesforce B2C Commerce (SFCC) is a managed, multi-tenant platform, which means Salesforce enforces hard boundaries on what your code, jobs, and integrations can do — not as an afterthought, but as a design principle of the platform itself. If you're reading this, you've probably already hit one: a job that silently truncates, an API integration returning 429s during a flash sale, or a custom object that stopped accepting new attributes.

The short answer: SFCC limits fall into four practical categories — API request quotas (OCAPI/SCAPI), job execution windows, data/storage caps (custom objects, attributes, logs), and sandbox lifecycle constraints. None of these are bugs. They're governance limits published by Salesforce and revised every release, and the teams that get burned are the ones who discover them in production instead of during architecture review. This guide walks through where they show up, how to design around them, and when hitting a limit is really a sign your architecture needs to change.

What "Platform Limits" Actually Means on a Managed Commerce Platform

SFCC's multi-tenant model is the trade-off you accept for not managing infrastructure. Salesforce guarantees uptime and patching; in exchange, every tenant shares finite resources — CPU per request, job runtime windows, API request buckets. These are documented in the B2C Commerce Infocenter under "Governance Limits" and they're not static: Salesforce adjusts numeric thresholds across releases, so hardcoding a specific number into your architecture doc is a mistake on day one. What doesn't change release to release is the category of limit and the failure mode it produces — that's what you actually need to design against.

There's also a distinction worth internalizing: soft limits (quota policies you can request an increase for, like OCAPI/SCAPI throughput) versus hard limits (structural constraints like job step chaining or attribute counts per system object type) that no support ticket will change. Knowing which bucket a limit falls into decides whether your fix is "open a case with Salesforce" or "redesign the integration."

The Limits That Actually Break Production

API Request Quotas (OCAPI and SCAPI)

Both OCAPI and SCAPI are governed by quota policies configured per client ID in Account Manager / Business Manager — requests per second/minute, scoped per API family. These aren't advertised as a single global number because they vary by client configuration and negotiated tier. The failure mode is consistent, though: once you exceed the bucket, the platform returns 429 Too Many Requests, and if your integration doesn't back off gracefully, you get cascading retries that make the throttling worse, not better.

This is the single most common limit we see teams hit during traffic spikes — flash sales, Black Friday, a marketing email blast that drives a synchronized wave of PDP hits. The fix isn't "ask for a bigger quota" (though that's part of it); it's designing the client to tolerate throttling: exponential backoff, request batching, and caching anything that doesn't need to be real-time.

Job Execution Windows

Jobs in SFCC run within a bounded execution window and are subject to step-level timeouts. A job that works fine against a QA catalog of 5,000 SKUs can silently degrade — or get killed mid-run — against a production catalog of 500,000. The common trap: a data feed job (price sync, inventory sync, catalog export) that was never load-tested against production data volume, and starts failing exactly when volume is highest — which, for retail, is exactly the wrong moment.

Custom Objects, Attributes, and System Object Extensions

Every custom attribute you add to a system object (Product, Customer, Order) counts against a governance limit, and once you're near it, adding "just one more field" for a new integration becomes a real architectural decision, not a five-minute Business Manager change. Teams that treat custom attributes as a free extension point for years eventually hit a wall exactly when they need to onboard a new PIM, loyalty system, or marketplace integration.

Sandbox Lifecycle and Storage

Sandboxes restart on a scheduled cycle and have finite code and data storage. This is well known but still catches teams off guard when a sandbox used for load testing or data migration loses state after a restart, or when log retention windows are shorter than the team assumed — turning a "let's check yesterday's logs" debugging session into a dead end.

A Real Trade-Off: When Quota Policy Meets Black Friday

We've seen this pattern repeat across different SFCC storefronts, including a global cosmetics brand's integration layer during a peak sales event: a middleware service polling OCAPI for order status updates, built and tested under normal traffic, started receiving 429 responses once concurrent order volume spiked. The middleware's retry logic had no backoff — it simply retried immediately — which meant the retries competed with legitimate storefront traffic for the same quota bucket, making the throttling worse under load, not better.

The fix wasn't a bigger quota request (though that helped). It was moving from polling to webhook-driven order notifications where possible, batching status checks instead of firing one request per order, and adding jittered exponential backoff so failures degraded gracefully instead of compounding. The lesson generalizes: quota limits punish naive retry logic far more than they punish reasonable traffic.

How to Architect Around SFCC Limits

Cache aggressively, invalidate deliberately. Anything that doesn't need to be real-time — category trees, static content, non-time-sensitive pricing — should be cached at the edge or in your PWA Kit/SFRA layer, not re-fetched from OCAPI/SCAPI on every request.
Batch instead of loop. One request for 100 records beats 100 requests for one record, every time quota is in play.
Design for 429 as an expected response, not an exception. Backoff with jitter, circuit breakers, and dead-letter queues for retries that keep failing.
Load-test jobs against production-scale data, not the QA catalog. Job runtime scales with data volume in ways that don't show up until it's too late.
Treat custom attributes as a budget, not a convenience. Track usage against the governance limit the same way you'd track a cloud spend budget.
Separate integration concerns from storefront concerns. A middleware/integration layer that owns retry logic, rate limiting, and queuing keeps quota pressure away from the customer-facing request path.

A Pre-Launch Checklist for SFCC Limits

Have you reviewed current governance limits in the Infocenter for your SFCC release (not last year's)?
Do you know your OCAPI/SCAPI quota policy per client ID, and has it been sized against expected peak concurrency?
Have all recurring jobs been load-tested against production-scale data volume, with alerting on runtime approaching the timeout window?
Is there headroom in custom attributes/custom objects for the next 12 months of planned integrations?
Does every external integration implement backoff and idempotent retries, not naive immediate retries?
Is there a documented owner for quota/limit monitoring — not just "whoever notices the outage"?

When Hitting a Limit Means It's Time to Rearchitect

Not every limit is a bug to route around. Sometimes hitting a governance limit repeatedly is the platform telling you the architecture has outgrown its current shape — that a synchronous integration should become async, that a monolithic job should be split into incremental steps, or that a headless front end (PWA Kit) would decouple storefront traffic from backend quota pressure entirely. The trade-off is real: rearchitecting costs time and short-term velocity. But teams that keep patching around the same limit release after release are paying that cost anyway, just spread out and compounding as technical debt.

If your team is hitting the same SFCC limit more than once a quarter, that's a signal worth escalating past the sprint backlog.