Limites da plataforma SFCC: o guia prático para não ser pego de surpresa

Se você lidera tecnologia em um e-commerce rodando em Salesforce B2C Commerce (SFCC), provavelmente já ouviu falar de algum limite de plataforma depois que ele já causou dor: uma chamada de API bloqueada em pleno pico de tráfego, um job que falha silenciosamente, um objeto customizado que não sincroniza mais porque a quota de armazenamento estourou. Os limites do SFCC não são segredo, estão documentados, mas raramente são tratados como parte da arquitetura até que virem incidente.

Este guia resume as categorias de limites que mais afetam operações de e-commerce em crescimento, por que eles se tornam críticos em momentos de pico (Black Friday, lançamentos, campanhas pagas) e como montar uma rotina de monitoramento que evita descobrir esses limites em produção, na pior hora possível.

O que são os limites de plataforma no SFCC

SFCC é uma plataforma multi-tenant: a Salesforce garante performance e disponibilidade para todos os clientes na mesma infraestrutura impondo limites técnicos, de chamadas de API, de armazenamento, de execução de jobs, de tamanho de payload, entre outros. Esses valores existem para proteger a estabilidade do ambiente compartilhado, não para dificultar o trabalho do time de tecnologia.

O problema não é a existência dos limites. É que eles mudam por release, variam por tipo de instância (Sandbox, Staging, Production) e nem sempre aparecem no radar de quem está sob pressão de prazo, focado em entregar a próxima feature. Os valores exatos de cada limite estão nos documentos oficiais da Salesforce ("Platform Feature and Usage Limits" no Infocenter/Salesforce Developer Center) e devem ser consultados na versão vigente do seu ambiente. Não vale confiar em números fixos de artigos antigos, porque eles são atualizados com frequência.

Os principais limites que pegam times de tech de surpresa

Limites de API: OCAPI e SCAPI rate limit

OCAPI (legado) e SCAPI (a API moderna, base para arquiteturas headless com PWA Kit) impõem limites de taxa de requisição por site e por client ID. Isso é especialmente relevante em três cenários:

Integrações headless: um frontend em PWA Kit ou uma aplicação React consumindo SCAPI intensamente para catálogo, busca e checkout pode esbarrar no rate limit se não houver cache adequado (CDN, cache de sessão, cache de resposta).
Integrações de middleware: ERPs, PIMs e OMS sincronizando dados via API em lote precisam de estratégia de throttling e retry, não de "força bruta".
Picos sazonais: tráfego 5x, 10x acima do normal em campanhas promocionais expõe rate limits que nunca apareceram em testes de carga subdimensionados.

Trade-off real: aumentar cache reduz chamadas à API, mas também aumenta a janela de dados potencialmente desatualizados (preço, estoque). A decisão de TTL de cache é uma decisão de negócio, não só técnica. Vale alinhar com o time de produto o quanto de "atraso" é tolerável para cada tipo de dado.

Limites de Custom Objects e atributos de sistema

SFCC limita o número de atributos customizados por objeto de sistema e o volume de dados em Custom Objects. Times que usam Custom Objects como banco de dados auxiliar (para logs de integração, filas de sincronização, configurações dinâmicas) costumam crescer esse volume sem monitorar, até que a quota de armazenamento vira gargalo de performance ou bloqueio de escrita.

Exemplo concreto (sem novidade nenhuma para quem já passou por isso): em uma migração de catálogo para um varejista de moda que atende o mercado americano, o time de integração usou Custom Objects para rastrear o status de sincronização de cada SKU durante a migração. Sem rotina de limpeza, o volume de registros cresceu além do previsto e passou a impactar o tempo de resposta de jobs que liam esses objetos. A correção não foi arquitetural, foi processual: rotina de expurgo automático e monitoramento de volume.

Limites de Jobs e processamento em lote

Jobs no Business Manager têm limites de tempo de execução e de concorrência. Jobs mal dimensionados (processando catálogo inteiro em vez de deltas, por exemplo) tendem a estourar o tempo de execução em ambientes com volume de dados maior do que o esperado no desenho original.

Isso costuma aparecer como "o job está lento", mas na raiz é uma questão de arquitetura: processamento incremental vs. processamento total, particionamento de carga, paralelismo dentro dos limites de concorrência permitidos.

Limites de armazenamento e Digital Data

Catálogo, biblioteca de conteúdo e dados digitais (imagens, PDFs vinculados a produtos) também têm quotas de armazenamento por instância. Times que centralizam ativos digitais dentro do SFCC em vez de usar um CDN/DAM externo tendem a esbarrar nesse limite conforme o catálogo escala, especialmente em operações multi-marca ou multi-região.

Por que esses limites importam mais em picos de tráfego

Em operação normal, muitos desses limites parecem folgados. O problema é que e-commerce não vive em operação normal: Black Friday, lançamentos de produto, campanhas de mídia paga e picos sazonais concentram tráfego e volume de transações em janelas curtas. É exatamente nesse momento que:

Rate limits de API que nunca foram atingidos em testes de carga "normais" se tornam realidade.
Jobs de sincronização de estoque, que rodavam confortavelmente fora do horário de pico, competem por janela de execução com outros processos críticos.
Picos de criação de sessão e carrinho pressionam limites de armazenamento e de chamadas que ninguém tinha modelado.

A lição prática para o Tech Lead: teste de carga não deve simular só volume de usuários, deve simular volume de chamadas de API, de jobs concorrentes e de escrita em Custom Objects nas condições de pico real, não na média do ano.

Como monitorar e mitigar limites antes que virem incidente

Não existe bala de prata, mas existe rotina. Algumas práticas que reduzem o risco de forma consistente:

Auditoria trimestral de limites: revisar a documentação oficial de "Usage Limits" da versão atual do SFCC e comparar com o uso real da instância (via logs, via Business Manager, via monitoramento de API).
Alertas proativos: configurar alertas de uso de quota (quando disponíveis via logs ou ferramentas de observabilidade) em vez de descobrir o limite quando a chamada já falhou.
Cache como primeira linha de defesa para rate limit de API: CDN, cache de aplicação e cache de sessão bem configurados reduzem drasticamente o volume de chamadas diretas à API.
Processamento incremental em vez de full sync: jobs que processam apenas deltas evitam estourar tempo de execução e reduzem pressão sobre limites de concorrência.
Rotina de expurgo em Custom Objects: dados temporários (logs, filas, status de integração) precisam de política de retenção, não podem crescer indefinidamente.
Teste de carga alinhado ao pico real: simular o volume esperado na Black Friday, não o volume médio do trimestre anterior.

Trade-offs reais: performance, custo e prazo

Toda decisão relacionada a limites de plataforma é, no fundo, um trade-off de negócio disfarçado de decisão técnica:

Mais cache significa menos chamadas de API, mas dados potencialmente desatualizados. Decida o TTL junto com o time de produto, por tipo de dado.
Processamento incremental é mais robusto, mas exige mais esforço de desenho inicial do que simplesmente rodar full sync até funcionar.
Migrar ativos digitais para um DAM/CDN externo reduz pressão sobre quota de storage do SFCC, mas adiciona uma integração a mais para manter.
Monitoramento proativo tem custo de setup, mas é ordens de grandeza mais barato do que um incidente em pico de vendas.

Nenhuma dessas decisões é puramente técnica. O papel do Tech Lead aqui é traduzir o trade-off para quem decide prioridade e orçamento, e não deixar que o limite seja descoberto pela equipe de operação no meio de uma campanha.

Checklist rápido para Tech Leads

Você sabe, hoje, quais são os limites de rate limit de API (OCAPI/SCAPI) vigentes para a versão do seu ambiente?
Seus jobs de sincronização são incrementais ou full sync?
Existe rotina de expurgo para Custom Objects usados como fila/log?
Seu último teste de carga simulou volume de chamadas de API e concorrência de jobs, ou só volume de usuários?
Existe alerta configurado para uso de quota, ou a equipe só descobre o limite quando algo falha?

Se a resposta para a maioria dessas perguntas for "não sei" ou "não", vale tratar isso como item de arquitetura na próxima sprint, não como debt eterno.

Precisa de um diagnóstico técnico da sua instância SFCC?

A Develoci trabalha com arquitetura SFCC (SFRA e PWA Kit) para operações de e-commerce que não podem se dar ao luxo de descobrir um limite de plataforma durante um pico de vendas. Se sua equipe está sob pressão de prazo e sem capacidade extra de time, uma auditoria técnica focada pode identificar riscos de limite antes que virem incidente, e priorizar as correções que realmente importam para o próximo pico.