O Que É Intermediario

Entendendo o papel do intermediário em sistemas e transações

Um intermediário é qualquer entidade, serviço ou componente que fica entre duas partes e facilita a comunicação, transação ou processamento sem ser o agente final. Pode ser uma empresa, um software, uma API, um pagamento via plataforma — o conceito é simples, mas a execução é onde as coisas complicam. No desenvolvimento de software, o intermediário mais comum é um serviço de mensageria ou um gateway. Ele recebe requisições de um lado, faz algo com elas e repassa para o outro lado. O kafka, o rabbitmq, o kong — todos são intermediários de algum tipo. A diferença é que alguns intermediários fazem mais do que apenas passar a mensagem. Eles filtram, transformam, fazem load balancing, rate limiting, caching, e por aí vai. No mundo dos pagamentos, o intermediário é a operadora do cartão, a Stripe, o PagSeguro. Você vende um produto, o cliente paga, e o dinheiro passa por esse meio antes de chegar na sua conta. Isso não é ruim por si só, mas você paga entre 1% e 6% por isso, dependendo do volume e do provider.

No mercado B2B, o intermediário é o distribuidor, o representante comercial, o marketplace. A Alibaba é um intermediário gigantesco. O Mercado Livre também. Você vende direto? Não, você vende para o cliente final através deles, e eles levam uma taxa que pode variar de 11% a 20% em alguns casos. O que muitas pessoas não percebem é que um intermediário bem configurado pode reduzir o tempo de integração com novos provedores de cerca de 3 semanas para 2 dias. Mas um intermediário mal configurado vai gerar pontos de falha únicos e tornar a depuração uma dor de cabeça enorme. Achei isso na pior forma quando tive que rastrear um problema de timeout num fluxo de pagamento que passava por três camadas de intermediário: o gateway do cliente, a API de processamento do marketplace, e o banco adquirente. Cada um tinha um timeout diferente, e o erro mais simples era mascarado pelo mais rápido. A solução foi implementar trace IDs correlacionados em todas as três pontas e um monitoramento de latência por camada, não apenas no final do fluxo. Isso reduziu o tempo médio de resolução de problemas de 4 horas para cerca de 25 minutos.

Como funcionam os intermediários em arquiteturas modernas

O padrão mais básico é o reverse proxy. Ele recebe a requisição do cliente, decide para qual backend encaminhar, e devolve a resposta. Nginx, Traefik, Envoy fazem isso. A vantagem é que você pode mudar seus backends sem o cliente saber que mudou nada. A desvantagem é que cada hop adicional adiciona latência e um ponto de falha a mais. Em arquiteturas de microsserviços, o intermediário de comunicação mais comum é o service mesh. O Istio é o exemplo mais conhecido. Ele injeta um sidecar proxy em cada serviço e controla todo o tráfego entre eles. Isso dá visibilidade completa, política de segurança centralizada, e capacidade de fazer canary deployments sem tocar no código dos serviços. O custo é que a complexidade operacional aumenta significativamente, e o overhead de latência costuma ficar entre 1ms e 5ms por saltos, dependendo da configuração. Para quem está começando, um erro muito comum é achar que menos intermediários é sempre melhor. Não é. Um sistema monolítico com tudo em um único ponto é mais rápido em termos de latência, mas é um pesadelo para escalar e manter. O equilíbrio certo depende do volume de transações, da criticidade do sistema, e da equipe disponível para operar.

Um insight contraintuitivo é que em muitos casos, ter mais de um intermediário intencionalmente melhora a resiliência. Se você tem um API gateway que faz caching, e atrás dele um service mesh que faz retry inteligente, uma falha no gateway não derruba tudo — o service mesh pode servir respostas em cache ou tentar rotas alternativas. O problema é que essa arquitetura exige que cada camada tenha timeouts bem definidos e que as mensagens de erro sejam propagadas corretamente, o que raramente é feito desde o início.

Quando um intermediário é dispensável

Se você está fazendo um projeto interno com menos de 10 pessoas usando, sem SLA externo, e o orçamento de infraestrutura é menor que 500 reais por mês, um intermediário desnecessário só vai adicionar complexidade sem benefício. Um direct connection entre o cliente e o serviço é suficiente. Intermediários são necessários quando você precisa de abstração, segurança, escala heterogênea, ou múltiplos provedores. Se o seu negócio depende de três gateways de pagamento diferentes porque um cai toda semana, você precisa de um intermediário que faça failover automático entre eles. Nesse caso, construir um orquestrador customizado ou usar um serviço como o Braintree com múltiplos adapters resolve o problema em questão de dias, não meses. O risco maior de intermediários é o vendor lock-in. Quando você depende de um intermediário proprietário para gerenciar suas integrações, migrar fica caro e lento. Eu vi uma empresa gastar cerca de 6 meses e R$ 180 mil para sair de uma plataforma de integração que parecia robusta no início, mas que não exportava metadados de forma compatível. A lição é simples: exija contratos de portabilidade de dados e mantenha o know-how das integrações dentro da sua equipe, não apenas no provider.

Se o seu caso é simplesmente conectar dois sistemas internos e o volume é baixo, um webhook ou uma fila simples com Redis já resolve. Não adicione um Kafka, um Kong, e um service mesh só porque é moda. Você vai se arrepender quando precisar depurar um problema às 3 da manhã.