Leonardo Peron5 min de leitura
A pergunta aparece depois que a primeira já foi respondida. Alguém decidiu que os sistemas precisam conversar, e agora surge a bifurcação: contratar uma plataforma que já sabe falar com os dois lados, ou escrever a conexão direta. Hub de integração, plataforma de integração, iPaaS — nomes diferentes para a mesma ideia de um intermediário no meio do caminho.
A resposta honesta não é uma das duas. É saber o que se compra e o que se paga em cada uma, porque a decisão erra por motivo previsível: comparar o preço da licença com o preço de escrever, e ignorar o resto.
O que o hub realmente é
Um middleware empacotado como produto. Ele traz conectores prontos para sistemas conhecidos, uma tela onde se define de qual campo para qual campo o dado vai, um motor que executa isso no horário ou no evento, e um registro do que passou.
A promessa é tirar do seu time o trabalho que não é do seu negócio: descobrir como o outro lado autentica e o que ele chama de pedido. A promessa é real; o que fica mal dimensionado é a fronteira dela.
O que ele resolve de verdade
O conector já foi escrito por outra pessoa. O levantamento é a fase mais longa e menos visível de qualquer integração — ler documentação, testar o que ela não diz, descobrir o campo que só aparece em certo tipo de pedido. Quando o conector cobre o seu caso, esse tempo não acontece.
O monitoramento vem junto. Painel de execução, histórico por mensagem, fila de erro e reprocesso são a parte que times internos deixam por último e às vezes nunca fazem — a diferença entre saber que uma troca parou e descobrir pelo cliente, que é o assunto de a fila que ninguém olha. Num hub, isso é o produto.
Alguém mantém quando a API do outro lado muda. É o item mais subestimado e provavelmente o de maior valor. Plataforma de venda e marketplace mudam regra, campo e obrigatoriedade por conta própria, e a integração quebra sem ter sido tocada. Com conexão direta, essa sustentação é sua para sempre, sobre código que ninguém abre há meses. Com hub, está no contrato de quem vendeu o conector.
O que ele cobra por isso
O preço quase nunca é por sistema conectado. É por transação, por execução, por volume de mensagens ou por conector ativo — e o modelo importa mais que o valor, porque é ele que decide como a conta cresce.
Há um custo fora da fatura: a lógica de mapeamento passa a morar dentro do produto. Ela existe em telas, não num repositório que você versiona, revisa e leva embora. Trocar de hub depois significa refazer o mapeamento inteiro — é por isso que a decisão se comporta como escolha de longo prazo mesmo sendo vendida como assinatura mensal.
E há um teto de expressividade. Enquanto o fluxo for "pegue este campo e ponha naquele", a tela resolve. Quando entra regra própria — rateio entre filiais, tabela de preço por cliente, reserva de saldo com critério seu — ela vira código dentro do hub, numa linguagem que só serve ali, ou vira um serviço fora dele, e o hub deixa de ser a plataforma para virar mais uma peça no caminho.
Quando o custo por transação vira o problema
Não quando o negócio cresce. Quando o número de mensagens cresce mais rápido que a receita — são coisas diferentes, e é essa diferença que pega as pessoas de surpresa.
Um pedido é uma mensagem. Mas a atualização de saldo de um catálogo grande é uma mensagem por item por rodada, o status de entrega gera várias por pedido, e a sincronização de cadastro dispara sem ninguém ter vendido nada. A conta que engorda raramente é a do pedido: é a do tráfego de manutenção em volta dele, que também é o que esbarra em limite de requisições.
A projeção honesta, então, não se faz sobre pedidos por mês: faz-se listando cada fluxo, quantas mensagens ele produz por rodada e quantas rodadas existem por dia. Se o número cresce com o catálogo em vez de crescer com a venda, essa é a variável a vigiar.
Quando o hub é claramente a escolha certa
Quando os fluxos são poucos e padrão, entre sistemas populares, sem regra própria no meio do caminho. Quando não há time técnico interno para sustentar código de integração — e sustentar é o verbo que decide, não construir. E quando integrar é meio, não produto: a empresa vende outra coisa e precisa que isso funcione sem virar assunto.
Ele também é uma ponte legítima. Entrar com hub agora e trocar depois o que ficar caro é defensável, desde que a troca seja considerada desde o começo em vez de descoberta na renovação.
O que levantar antes de decidir
- A lista de fluxos, com quantas mensagens cada um gera por dia — não quantos pedidos a empresa faz.
- Quais desses fluxos têm regra que não cabe em "de tal campo para tal campo".
- Se existe conector pronto para os seus sistemas nas versões que você usa. Conector que trata pedido mas não trata devolução resolve metade.
- Quem sustenta o que sobrar de fora, e se essa pessoa existe.
- Como o mapeamento sai de lá, caso um dia precise sair.
- O que muda se a resposta for direta: as mesmas variáveis aparecem em o que determina o prazo, e a decisão anterior a esta está em o que é integração de ERP e no levantamento.
O teste que separa é o quinto item. Se ninguém souber dizer como o mapeamento sai do produto, a decisão não é sobre custo por transação — é sobre para quem vai a chave da sua operação.