Operar um gateway SMS self-hosted: o que isso realmente exige

Um gateway SMS self-hosted é uma daquelas coisas que parecem simples vistas de fora e mostram a sua forma real na semana em que entram em produção. Enviar uma mensagem é fácil; enviar milhões de forma confiável, cobrar cada uma corretamente, comprovar a entrega e fazer tudo isso sem uma falha de madrugada é o trabalho de verdade. Este guia apresenta a arquitetura em termos simples, traz números de hardware honestos, marca o ponto em que o software gratuito para e descreve as operações que ficam sob a sua responsabilidade assim que o tráfego se torna real. O objetivo é ajudar você a decidir com pleno conhecimento, seja para desenvolver, comprar ou continuar alugando por mais algum tempo.

O que é, de fato, um gateway SMS self-hosted

Por trás dos painéis, um gateway é uma pequena linha de produção com quatro etapas. O tráfego entra, é colocado em fila, é enviado e é contabilizado. Entender essas quatro etapas já resolve a maior parte do desafio.

A entrada é a forma como as mensagens chegam. Os clientes corporativos enviam por uma API HTTP, que é mais prática; por um painel web, para campanhas pontuais; ou por um bind SMPP, quando são outra plataforma enviando grande volume. O SMPP é o protocolo nativo das telecomunicações: uma conexão TCP persistente, autenticada uma única vez, pela qual as mensagens passam a trafegar em fluxo contínuo como pacotes binários. Um cliente SMPP bem configurado consegue submeter dezenas de milhares de mensagens por segundo, e é exatamente por isso que os remetentes de grande volume o preferem ao HTTP.

A fila funciona como amortecedor. Você nunca envia diretamente da entrada para a operadora, porque as operadoras aceitam mensagens no próprio ritmo, e os seus picos de entrada não acompanham esse ritmo. Em vez disso, cada mensagem aceita vai para uma fila rápida em memória (o Redis é a escolha mais comum) e uma confirmação de recebimento é devolvida imediatamente. É isso que permite aceitar um disparo de um milhão de mensagens em segundos sem perder nenhuma e, depois, entregá-las às operadoras de forma constante. A persistência dessa fila é importante: se o servidor reiniciar e a fila estiver apenas em memória, tudo o que ainda não foi gravado em disco se perde.

O bearer, a camada de transporte, é a parte que de fato se comunica com as operadoras. Na maioria dos stacks self-hosted, esse papel é do Kannel, cujo BearerBox sustenta as conexões SMPP persistentes com cada SMSC (a central de mensagens da operadora), mantém essas conexões ativas, reconecta quando elas caem e distribui o tráfego entre as sessões. Um processo auxiliar lê a fila de mensagens pendentes e as entrega ao bearer; outro trata as confirmações de entrega e as mensagens recebidas que chegam de volta. Essa camada existe há décadas e é extremamente confiável, e não há nenhum demérito em se apoiar nela.

O faturamento e a contabilidade são a etapa que todos subestimam. Cada mensagem precisa ser debitada do saldo do cliente certo antes do envio, tarifada de acordo com a rota utilizada, reembolsada corretamente quando uma operadora informa uma falha permanente e consolidada em uma fatura que o cliente consiga ler. Isso não é um recurso que se acrescenta depois; está presente em todas as outras etapas, e é onde os gateways amadores perdem dinheiro sem perceber.

Dimensionamento do servidor: o que você realmente precisa a 1, 10 e 50 mensagens por segundo

O primeiro erro de dimensionamento é pensar em totais mensais. O tráfego de SMS acontece em picos: a promoção relâmpago de um varejista ou o processamento noturno de extratos de um banco faz passar o volume de um mês em uma hora. O que sobrecarrega o servidor é a vazão sustentada no pico, o volume de confirmações de entrega que retornam (muitas vezes tantos eventos quanto mensagens enviadas) e a carga de relatórios e buscas gerada pelos seus clientes. Dimensione para o pico, não para a média.

A tabela abaixo é um ponto de partida para uma implantação em um único nó, não um compromisso contratual. O tamanho da mensagem, a codificação, a combinação de rotas e o tempo de retenção dos registros alteram esses números.

Vazão sustentada	Volume mensal aproximado	Hardware inicial (nó único)	O que costuma falhar primeiro
~1 msg/s	Até ~1.000.000	4 vCPU, 8 GB RAM, SSD de 100 GB, todos os componentes juntos	Disco enchendo com logs e DLRs
~10 msg/s	~1.000.000 a 10.000.000	8 vCPU, 16 a 32 GB RAM, SSD de 250 a 500 GB	Busca e relatórios sob a carga dos clientes
~50 msg/s	10.000.000 ou mais	16+ vCPU, 32 a 64 GB RAM, NVMe rápido, componentes divididos entre nós	Limites de um nó único; hora de adotar active-active

Duas observações práticas. Primeira: a vazão para uma mesma operadora normalmente é limitada pelo número de sessões SMPP que a operadora permite, e não pelo seu hardware; se uma rota está lenta enquanto o seu servidor está ocioso, você provavelmente precisa de mais sessões, até o máximo permitido pela operadora, e não de um servidor maior. Segunda: assim que a plataforma se tornar crítica para o negócio, pare de escalar um único servidor e migre para uma topologia de alta disponibilidade, com os componentes em nós dedicados. Uma linha de base documentada, obtida na sua própria implantação, vale mais do que qualquer tabela genérica, porque o “normal” é definido em relação ao seu hardware e ao seu tráfego.

O que o código aberto oferece e onde ele para

O ecossistema de SMS de código aberto é realmente bom, e fingir o contrário é desperdiçar dinheiro. Kannel e Jasmin fazem a terminação SMPP, mantêm os binds com as operadoras e movimentam volumes enormes pelo preço do servidor. Se você precisa apenas de um canal direto entre um sistema e uma operadora, muitas vezes eles são a resposta certa, e você não deve comprar mais do que precisa.

Onde eles param é na camada de negócio, e essa lacuna é maior do que parece. Na instalação padrão, você não tem nenhuma administração gráfica, então cada rota, tarifa e usuário é um arquivo de configuração. Você não tem contas de cliente multi-tenant, o que significa nenhum isolamento, saldo ou tarifa por cliente. Você não tem faturamento, emissão de faturas nem controle de crédito. Você não tem portais white-label para clientes, os relatórios de entrega legíveis que os clientes pedem, um mecanismo de opt-out nem alguém para quem ligar quando um bind cai à meia-noite. Nada disso é uma crítica às ferramentas; elas foram criadas para ser um bearer, não um produto. Isso significa apenas que transformar um bearer em um negócio é um projeto de software, e você deve estimar o custo desse projeto com honestidade antes de começá-lo. Esse custo real do “gratuito” é o tema de uma comparação específica.

As operações sobre as quais ninguém alerta

Entrar em produção é o início do trabalho, não o fim. Quatro realidades operacionais vão definir se o seu gateway é um negócio ou uma fonte constante de problemas.

As confirmações de entrega (DLRs) são a forma de comprovar que uma mensagem chegou, e não são opcionais. A operadora devolve uma confirmação informando entregue, falha ou expirada, e a sua plataforma precisa associá-la à mensagem original, atualizar o relatório do cliente e decidir a cobrança. Uma falha temporária (aparelho desligado, congestionamento da rede) ainda pode ser entregue dentro do período de validade e não deve ser reembolsada antes da hora; uma falha permanente (número inválido, bloqueado) nunca será entregue e deve ser reembolsada. Errar essa classificação faz você perder dinheiro com reembolsos que não deveria conceder ou irritar clientes cobrando por mensagens que nunca chegaram.

As novas tentativas e a validade determinam o que acontece com as mensagens que não passam na primeira vez. Você precisa de uma política de novas tentativas sensata e de um período de validade; caso contrário, uma rota travada acumula silenciosamente tráfego não entregue até que um cliente pergunte por que a campanha dele nunca foi enviada.

O monitoramento é a diferença entre descobrir um problema por um gráfico e descobrir por um cliente irritado. No mínimo, acompanhe o status dos binds com as operadoras, a profundidade da fila, a taxa de entrega por rota e o espaço livre em disco. Um gateway sem monitoramento não é um gateway menor; é um problema sério que só espera o momento de aparecer, por melhores que sejam as intenções. Uma realidade simples que vale a pena ter sempre em mente: uma parcela surpreendente dos incidentes do tipo “está tudo quebrado” é simplesmente um disco cheio, então verifique isso primeiro.

Os backups são a etapa que você vai se arrepender de ter deixado de lado. O seu sistema de registro principal, a sua lista de clientes, os seus saldos e a persistência da sua fila precisam de um backup que você tenha realmente testado com uma restauração, e não apenas agendado. Teste uma vez antes de ter clientes, porque o dia em que você precisar dele é o pior dia possível para descobrir que ele nunca funcionou.

Desenvolver ou comprar, com honestidade

Esta é a escolha, sem discurso de vendas. Se você tem tempo de engenharia, gosta de ser dono do stack e o próprio canal de mensageria é o seu produto, desenvolver sobre código aberto é legítimo e barato em termos de licença. Você vai gastar essa economia nos meses necessários para desenvolver as camadas de faturamento, multi-tenant, portal e relatórios, e em mantê-las para sempre, mas para algumas equipes essa é exatamente a troca certa.

Se, por outro lado, o seu objetivo é vender mensageria a clientes neste trimestre, comprar uma plataforma que seja totalmente sua costuma ser a conta mais vantajosa. Uma plataforma com licença de pagamento único, como o Smppcube, já traz toda a camada de negócio, as contas multi-tenant, o faturamento, os portais e os relatórios, sobre o mesmo bearer comprovado em produção, e roda no seu próprio servidor, para que você mantenha a postura de air-gap ou DMZ que muitas vezes é justamente o motivo para escolher uma solução self-hosted. Você troca o valor de uma licença por seis a doze meses que deixa de gastar desenvolvendo um software que não é o seu diferencial.

O teste honesto é simples: escrever software de gateway é o seu negócio ou uma distração dele? Responda isso primeiro, e a arquitetura, o dimensionamento e as operações descritos acima se tornam uma lista de verificação, e não uma surpresa. Comece pelo seu próprio número de vazão de pico e por uma visão clara de para quem você vende, e o restante da decisão se resolve naturalmente.