Founder · Enterprise SoftwareScalegrid — Building a Connected Enterprise Platform
Arquitetura de software empresarial para integrar ERP, comércio digital, operações e processos em uma única plataforma.
Contexto
O projeto e o problema que ele resolve
Scalegrid é um ecossistema de aplicações empresariais: uma plataforma comum, módulos de ERP, comércio digital, integrações e automações, em produção em scalegrid.com.br.
O desafio central é oferecer modularidade sem transformar cada área da empresa em um sistema isolado — financeiro, CRM, projetos, contratos, estoque, RH e vendas precisam compartilhar o mesmo tenant, as mesmas permissões e os mesmos eventos.
A plataforma evoluiu por versões documentadas e por 32 decisões de arquitetura registradas, combinando uma base comercial licenciada com módulos e camadas próprias de domínio, integração e IA.
Problemas de negócio e engenharia
- 01
Sistemas desconectados
Quando financeiro, vendas e estoque vivem em ferramentas separadas, surgem sincronização manual, inconsistência e retrabalho.
- 02
Isolamento entre empresas
Dados de cada workspace precisam permanecer isolados sem multiplicar a operação.
- 03
Evolução sem fragmentação
Novos módulos não podem criar sistemas paralelos de tenant, permissão ou catálogo.
- 04
Integração confiável
Eventos, webhooks e pagamentos precisam ser entregues uma vez, com rastreabilidade e reprocesso.
Papel de Wendeel
Responsabilidades
Criador · Founder
Criador da Scalegrid, responsável pela visão tecnológica e pela arquitetura da plataforma.
Papel declarado por Wendeel
- Definição da arquitetura em monólito modular e do modelo de tenancy por workspace.
- Desenho da camada de eventos de domínio, outbox e entrega de webhooks.
- Estratégia de migração incremental do legado (Strangler Fig) e versionamento por changelog.
- Hub de integrações, cofre de credenciais e API pública com identificadores próprios.
Visão arquitetural
Como o sistema se organiza
Uma única aplicação com fronteiras explícitas: plataforma, núcleo compartilhado, módulos de domínio e uma camada de integração orientada a eventos.
Identity & Access
Em produçãoUsuários, papéis e permissões por cargo, com credenciais de API próprias.
- Permissões por cargo e por plano de módulos.
- Credenciais de API próprias da plataforma (ADR-020).
—
Representação simplificada da arquitetura documentada nos ADRs da Scalegrid. Os status refletem o que foi verificado em outubro de 2026.
Componentes e integrações
Plataforma
Em produçãoEmpresas, workspaces, usuários, planos, módulos e permissões.
Scalegrid ERP
Em produçãoGestão interna: financeiro, CRM, projetos, contratos, RH, metas, orçamentos e demonstrativos.
Scalegrid Commerce
Em produçãoLojas com domínio e tema próprios, catálogo, pedidos e pagamentos, integrada por SSO assinado.
Módulos próprios
Em produção22 módulos de plataforma (kernel, identidade, integrações, webhooks, fluxos, IA, adoção) e 7 conectores.
Ferramentas de IA e MCP
ExperimentalExposição de capacidades da plataforma a agentes por meio de ferramentas e servidor MCP.
Decisões técnicas
Escolhas documentadas e seus custos
Monólito modular em vez de microsserviços
Muitos domínios, um time enxuto e a necessidade de consistência entre financeiro, estoque e pedidos.
Módulos fisicamente separados, com fronteiras explícitas, dentro da mesma aplicação e do mesmo deploy.
- Transação ACID entre domínios.
- Um deploy; refatoração de fronteira barata; debug local completo.
- Um módulo defeituoso pode derrubar a aplicação inteira.
- Escala apenas a aplicação como um todo; a disciplina de fronteira depende de revisão, não do compilador.
Workspace como única unidade de tenancy
Módulos de origens diferentes chegavam com noções próprias de “dono” dos dados.
O workspace é o único tenant; todo acesso passa por um contexto de workspace, e nenhum módulo cria sistema paralelo.
- Um único modelo de isolamento para auditar e testar.
- Módulos legados mantêm a coluna original por compatibilidade, sem renomear colunas em produção.
Outbox transacional para eventos de domínio
Salvar o estado e publicar o evento em passos separados permite perder um dos dois.
Gravar o evento na tabela de outbox dentro da mesma transação do agregado.
- “Estado salvo” e “evento registrado” tornam-se atômicos.
- Mais uma tabela e um processo de despacho para operar.
Strangler Fig para migrar o legado
A plataforma já estava em produção enquanto a nova arquitetura era introduzida.
Substituir partes do legado módulo a módulo, desativando o antigo só após comprovar equivalência.
- Produção estável durante a migração; rollback por módulo.
- Convivência temporária de estilos — aceita e explícita.
IDs públicos ULID na API
A API pública não deve expor identificadores internos nem permitir enumeração.
Coluna pública ULID apenas nas tabelas expostas; a API aceita e devolve somente esse identificador.
- Ordenável por tempo e amigável a índices; nenhuma chave estrangeira muda.
- Uma fachada de identificador a manter nas tabelas expostas.
Redis para fila e cache, um worker por fila
Webhooks e integrações não podem disputar a mesma fila com tarefas gerais.
Fila e cache em Redis, filas nomeadas por responsabilidade e um worker por fila; sessões permanecem no banco.
- Isolamento de carga entre integrações e tarefas gerais.
- Mais um serviço para operar.
Trade-offs e desafios
Do problema à abordagem
Multi-tenancy
Manter o isolamento entre empresas e workspaces em um banco compartilhado.
Escopo global por workspace aplicado aos modelos e um contexto de workspace explícito, em vez de helpers globais.
RBAC
Controlar permissões por cargo, módulo e plano.
Permissões por cargo combinadas a um bloqueio de módulos por plano.
Dados compartilhados
Conectar catálogo, estoque, pedidos e financeiro sem duplicar fontes de verdade.
Catálogo único do núcleo, estoque com reserva atômica e livro de movimentações; o catálogo duplicado foi aposentado.
Integrações confiáveis
Entregar eventos a sistemas externos com segurança e reprocesso.
Webhooks assinados com HMAC, retentativas agendadas, cofre de credenciais e fila dedicada.
Pagamentos idempotentes
Notificações de pagamento chegam duplicadas ou fora de ordem.
Idempotência em três camadas no fluxo de pagamento.
Tecnologias verificadas
Backend
- PHP 8.3
- Laravel 12
- Módulos empacotados
- Permissões por cargo
Frontend
- Inertia
- React 18
- TypeScript
- Vite
- Tailwind
Dados e mensageria
- MySQL 8
- Redis (fila e cache)
- Outbox transacional
Operação e qualidade
- Workers systemd por fila
- Caddy + TLS
- Staging separado
- PHPUnit
Resultados e evidências
Evidências verificáveis e indicadores
Verificável
- Em produção em scalegrid.com.br desde agosto de 2026.
- 32 decisões de arquitetura registradas como ADRs.
- 13 versões publicadas no changelog da plataforma.
- 22 módulos próprios de plataforma e 7 conectores de integração.
Indicadores
Indicadores de uso da Scalegrid ainda não são publicados aqui. Números e depoimentos exibidos como demonstração em materiais do produto não são resultados medidos.
Aprendizados
O que este projeto ensina
- 01
Monólito modular é uma decisão de time e de consistência, não um passo atrás.
- 02
Tenancy precisa de um único dono no código; dois modelos de tenant viram dois bugs de isolamento.
- 03
Eventos sem outbox são uma promessa que o sistema não consegue cumprir sob falha.
- 04
Registrar decisões enquanto se constrói acelera o próprio time, não só quem chega depois.