Requisitos de servidor para gateway SMS: dimensionamento de 1 a 200 msg/s

“De que servidor eu preciso?” é a primeira pergunta de quase todo comprador, e a resposta envolve menos servidor do que a maioria das pessoas teme e é mais específica do que a maioria dos fornecedores costuma dizer. Um gateway SMS não é um codificador de vídeo. O trabalho dele é enfileirar, rotear, cobrar e registrar, e são os registros que crescem. Este guia apresenta os requisitos de servidor de um gateway SMS em cada faixa de tráfego, com números reais, explica por que a vCPU dedicada importa mais do que o número de núcleos, mostra o que as confirmações de entrega e os arquivos fazem com o seu disco ao longo de um ano e termina com uma lista curta de provedores e o plano de backup que você deve ter antes de o primeiro cliente entrar em produção.

Requisitos de servidor para gateway SMS por faixa de tráfego

O número que define o seu servidor é o de mensagens por segundo no pico, e não o de mensagens por mês. Um cliente que envia 1.000.000 de mensagens distribuídas ao longo de um mês tem uma média de 0,4 msg/s; o mesmo cliente disparando uma promoção para 200.000 números às nove da manhã precisa de 100 msg/s durante meia hora. O gateway precisa absorver esse pico, entregá-lo às operadoras tão rápido quanto elas aceitarem e, depois, receber as confirmações de entrega que retornam, que no pico chegam na mesma taxa em que os envios saíram.

A tabela abaixo é o dimensionamento que publicamos na página da plataforma, e corresponde ao que as nossas próprias instalações utilizam. Os volumes são mensais; as taxas são sustentadas.

Taxa sustentada	Volume mensal	Servidor	Observações
~1 msg/s	até ~1.000.000 SMS	4 vCPU, 8 GB de RAM, SSD de 100 GB, tudo em um único servidor	A maioria dos revendedores fica nesta faixa no primeiro ano
~10 msg/s	~1.000.000 a 10.000.000	8 vCPU, 16 a 32 GB de RAM, SSD de 250 a 500 GB	Índice de busca e banco de dados, idealmente, em discos próprios
~50 msg/s ou mais	10.000.000 ou mais	16+ vCPU, 32 a 64 GB de RAM, NVMe rápido, componentes divididos entre nós	Fila, banco de dados, busca e camada SMPP têm, cada um, o seu próprio espaço

Duas coisas nesta tabela surpreendem as pessoas. Primeira: como a primeira faixa é pequena. Uma plataforma multi-tenant completa, com console web, servidor SMPP, fila, banco de dados e índice de busca, cabe em um servidor de 4 vCPU, porque a 1 msg/s nenhum desses componentes está sob pressão. Segunda: o salto para a terceira faixa não tem a ver com CPU. Tem a ver com I/O: a 50 msg/s, o banco de dados grava uma linha por mensagem, atualiza essa linha quando a operadora confirma o recebimento, atualiza de novo quando a confirmação de entrega chega e a indexa para a busca. Três gravações por mensagem a 50 msg/s são 150 gravações por segundo, de forma sustentada, mais as leituras de cada painel de cliente que estiver aberto. Isso é um problema de disco, e é por isso que o NVMe e os nós separados aparecem na terceira linha, e não antes.

A questão dos picos: começar pequeno, mas precisar de folga

Há um caso intermediário comum que a tabela não mostra: você está começando do zero, então o seu volume mensal é mínimo, mas o seu primeiro cliente é uma rede de escolas ou uma loja de e-commerce que envia tudo em um único pico pela manhã e espera que as mensagens cheguem em poucos minutos. Você precisa de folga para 100 a 200 msg/s enquanto a sua taxa sustentada ainda está abaixo de 1 msg/s.

A resposta é um servidor dedicado de 4 a 8 vCPU com 32 GB de RAM. Ele custa de US$ 50 a US$ 100 por mês nos provedores listados abaixo, absorve o pico porque os núcleos são seus e a RAM mantém a fila e o conjunto de dados de trabalho em memória, e atende você até que o volume sustentado, as confirmações de entrega e os relatórios comecem a disputar o mesmo disco. Esse é o momento de subir de faixa, e ele normalmente chega depois do décimo cliente, e não do primeiro.

O erro de iniciante mais caro neste negócio é comprar a terceira faixa no primeiro dia porque uma planilha dizia que você teria 50 clientes. Compre a primeira faixa preparada para picos, acompanhe o disco e a fila de confirmações e mude de faixa quando os gráficos indicarem que é hora.

vCPU dedicada versus compartilhada

As tabelas de preços de hospedagem deixam pouco clara uma distinção importante. Uma instância compartilhada de “4 vCPU” oferece quatro frações de tempo de núcleos que outros clientes do provedor também estão usando; uma instância dedicada de “4 vCPU” oferece quatro núcleos que são seus. Para um site, a diferença é imperceptível. Para um gateway SMS, é a diferença entre uma promoção chegar em dez minutos ou em quarenta.

O motivo é o formato da carga. O tráfego web é regular e tolerante; um segundo mais lento aqui e ali passa despercebido. O tráfego SMS acontece em picos e mantém estado: durante um pico, a camada SMPP precisa manter os binds com as operadoras abastecidos e responder aos heartbeats delas no tempo certo, a fila precisa ser esvaziada e as confirmações precisam ser associadas às mensagens enquanto essas mensagens ainda estão na memória ativa do banco de dados. Quando um núcleo compartilhado está sendo usado por um vizinho nesse momento, o bind trava, a janela da operadora se enche, a operadora limita o seu tráfego e as suas confirmações se acumulam atrás dos envios. Nada quebra, mas tudo o que você prometeu ao cliente sobre velocidade e relatórios agora está atrasado.

Regra prática: vCPU compartilhada para a demonstração e para o servidor de staging, vCPU dedicada para tudo aquilo pelo que um cliente paga. A diferença de preço na primeira faixa é de US$ 20 a US$ 40 por mês, menos do que vale uma hora do seu tempo explicando a um cliente por que o relatório de ontem ainda está sendo atualizado.

RAM: o que realmente fica em memória

A necessidade de memória é mais fácil de calcular. Três coisas precisam ficar residentes: a fila (cada mensagem aceita, mas ainda não entregue a uma operadora, mais cada confirmação ainda não associada), o conjunto de trabalho do banco de dados (as mensagens dos últimos dias, as tabelas de preços, as contas de clientes) e o cache do índice de busca. Na primeira faixa, os três juntos cabem em 8 GB, com espaço para o sistema operacional e o console web. Na segunda faixa, o conjunto de trabalho cresce com o seu histórico, e de 16 a 32 GB evitam que o banco de dados precise acessar o disco para os relatórios que os clientes abrem toda manhã.

Na prática, onde a RAM se esgota não é na fila, e sim nos relatórios. Um cliente que pede “todas as mensagens para este país no último trimestre” em um banco de dados que precisa ler isso do disco transforma uma consulta de dois segundos em uma de dois minutos e deixa todos os outros mais lentos enquanto ela roda. Adicionar RAM é a correção mais barata; arquivar as mensagens antigas em um banco de dados de documentos, que é o que o desenho dividido da terceira faixa faz, é a correção duradoura.

Disco: o crescimento vem das confirmações de entrega e dos arquivos

O disco é onde o crescimento real acontece, e é a parte que ninguém dimensiona. Cada mensagem enviada gera pelo menos três registros: a própria mensagem, a confirmação de entrega enviada pela operadora e o lançamento de cobrança que debitou o cliente. Somando os índices que tornam a busca e os relatórios rápidos, um valor prático de planejamento é de cerca de 1 KB por mensagem no total, antes da compressão.

Na primeira faixa, 1.000.000 de mensagens por mês representam cerca de 1 GB de crescimento por mês. Um SSD de 100 GB comporta anos disso. Na segunda faixa, 10.000.000 de mensagens por mês são 10 GB por mês, 120 GB por ano, e um índice de busca por cima disso acrescenta de 30% a 50%. É por isso que a segunda linha indica 250 a 500 GB e que o índice de busca e o banco de dados ficam “idealmente” em discos próprios: quando compartilham um disco, os dois disputam a mesma capacidade de gravação.

Duas decisões de projeto evitam que isso se torne um problema. Primeira: uma camada de arquivamento. O banco de dados principal mantém a janela recente (por exemplo, 90 dias) e as mensagens mais antigas vão para um banco de dados de documentos, onde continuam pesquisáveis, mas não deixam mais lentas as tabelas transacionais. Segunda: uma política de retenção que você realmente defina. Muitos operadores de gateway guardam as confirmações de entrega por 12 a 24 meses para tratar contestações e excluem antes o conteúdo das mensagens, e alguns mercados regulam o período de retenção, então confirme a regra dos países para os quais você envia. Uma plataforma com uma camada de arquivamento integrada, que é como o stack do Smppcube é desenhado, com o MongoDB como arquivo ao lado do MySQL como sistema de registro, transforma essas duas decisões em uma configuração, e não em um projeto.

Rede e portas

A largura de banda não é a limitação; uma mensagem tem algumas centenas de bytes. O que importa é um IP público estável, porque as operadoras normalmente incluem o IP do seu bind SMPP em uma allowlist e não gostam de atualizá-lo, e a porta de entrada 2775 aberta (ou a porta que você escolher) se os seus próprios clientes forem fazer bind no seu servidor SMPP. Além disso, você precisa de HTTPS para o console e para a API HTTP, e de acesso de saída aos endpoints SMPP e HTTP das operadoras. Se você opera em uma DMZ ou isolado da rede, o gateway só precisa dos links com as operadoras e da rede do console, e esse é um dos motivos pelos quais a solução self-hosted funciona em ambientes regulados onde um painel SaaS nem sequer pode ser aprovado.

Uma lista curta de provedores, com preços

Qualquer provedor que venda vCPU dedicada, armazenamento SSD ou NVMe e um IP estático, e que permita abrir uma porta, serve. Estes são os que vemos com mais frequência. Um servidor dedicado de 4 a 8 vCPU e 32 GB, que cobre a primeira faixa preparada para picos e a CPU e a RAM da segunda faixa, normalmente custa de US$ 50 a US$ 100 por mês em qualquer um dos quatro primeiros; a terceira faixa, com NVMe e nós separados, exige um orçamento sob medida em todos eles.

Provedor	Indicado para	Por que aparece
Hetzner	Europa	Planos com vCPU dedicada e servidores bare metal a preços baixos
Netcup	Europa	Núcleos dedicados a baixo custo; nós mesmos usamos a Netcup
DigitalOcean	Regiões no mundo todo	Console simples, preços previsíveis, snapshots fáceis
OVHcloud	Europa, América do Norte	Bare metal disponível quando as máquinas virtuais deixam de ser suficientes
Alibaba Cloud	Arábia Saudita e Golfo	Um data center dentro do Reino, para residência de dados
Seu próprio hardware	Ambientes isolados da rede ou regulados	Apenas as taxas de colocation; o gateway não precisa de nada externo além dos links com as operadoras

A menção “nós mesmos usamos a Netcup” está ali porque os compradores perguntam; é uma declaração do que funciona nas duas primeiras faixas, e não uma recomendação para ignorar os demais. Consulte as tabelas de preços atuais antes de decidir. Se os seus clientes estão em um único país, um provedor com uma região nesse país reduz o tempo de ida e volta até as operadoras e, mais importante, mantém os dados onde o regulador espera que eles estejam.

A conta completa, com honestidade

O dimensionamento do servidor só faz sentido ao lado do restante da conta, e é aqui que o modelo self-hosted justifica o nome. São três linhas, e só uma delas é nossa:

1. A licença, uma única vez: US$ 6.400 pela plataforma, com todos os canais, todos os recursos e o primeiro ano de suporte. Essa é a página de preços resumida em um único número.
2. O servidor, mensalmente: de US$ 50 a US$ 100 nas duas primeiras faixas, pagos ao provedor que você escolher, na sua própria conta, e você pode migrá-lo quando quiser.
3. O seu tráfego com as operadoras, nas tarifas que você negociar com o seu próprio SMSC ou agregador. Nós nunca ficamos no meio desse tráfego.

Compare isso com um painel alugado, em que a taxa da plataforma cresce com o seu tráfego e o servidor fica invisível porque pertence ao fornecedor: a linha do servidor é a única que você não consegue reduzir à medida que cresce, e aqui ela é a menor linha da conta.

Backups, monitoramento e as tarefas rotineiras

Um servidor não é um plano. Antes de o primeiro cliente entrar em produção, três coisas precisam existir e ter sido testadas:

• Um backup noturno que você já restaurou pelo menos uma vez. Dump do banco de dados mais o diretório de configuração, copiados para fora da máquina (o snapshot do provedor é prático, mas um snapshot na mesma conta do servidor não protege contra o bloqueio dessa conta). Teste a restauração no servidor de staging; um backup que ninguém restaurou não oferece nenhuma garantia.
• Alertas de disco e de fila. Dois limites bastam: disco acima de 80% e confirmações na fila há mais de 15 minutos. O primeiro indica que é hora de arquivar ou crescer; o segundo mostra que um bind com uma operadora não está saudável antes que um cliente avise.
• Um servidor de staging. O VPS compartilhado mais barato que você encontrar, rodando a mesma versão, onde as atualizações e as novas tabelas de preços são testadas primeiro. O custo mensal é irrisório; o valor está em cada atualização que você não precisa reverter no servidor de produção enquanto os clientes estão enviando.

Quando você não precisa de nada disso

Se você envia alguns milhares de mensagens por mês a partir de um único aplicativo e não tem clientes próprios, não precisa de um servidor de gateway; uma API HTTP de qualquer fornecedor, chamada pelo seu aplicativo, é a solução do tamanho certo. O dimensionamento deste guia é para empresas que vendem mensageria a terceiros: revendedores, agregadores, operadoras ou uma empresa que opera a mensageria de muitas equipes internas. Nesse ponto, o servidor é a parte mais barata do negócio, e saber em qual faixa você está, e o que vai levar você à próxima, é quase tudo o que “requisitos” sempre significou.