Requisitos de servidor para una pasarela SMS: de 1 a 200 msg/s

“¿Qué servidor necesito?” es la primera pregunta que hace casi todo comprador, y la respuesta es más pequeña de lo que la mayoría teme y más concreta de lo que dicen la mayoría de los proveedores. Una pasarela SMS no es un codificador de vídeo. Su trabajo consiste en poner en cola, enrutar, facturar y llevar la contabilidad, y lo que crece es la contabilidad. Esta guía le da los requisitos de servidor de una pasarela SMS en cada nivel de tráfico con cifras reales, explica por qué la vCPU dedicada importa más que el número de núcleos, muestra lo que los acuses de entrega y el archivo hacen con su disco a lo largo de un año, y termina con una lista corta de proveedores y el plan de copias de seguridad que debería tener antes de que el primer cliente entre en producción.

Requisitos de servidor de una pasarela SMS por nivel de tráfico

La cifra que decide su servidor son los mensajes por segundo en el pico, no los mensajes al mes. Un cliente que envía 1.000.000 de mensajes repartidos a lo largo de un mes promedia 0,4 msg/s; ese mismo cliente, al lanzar una promoción a 200.000 números a las nueve de la mañana, pide 100 msg/s durante media hora. La pasarela tiene que absorber esa ráfaga, entregarla a los operadores tan rápido como la acepten y después recoger los acuses de entrega que regresan, que en el pico llegan al mismo ritmo al que salieron los envíos.

La tabla siguiente es el dimensionamiento que publicamos en la página de la plataforma, y coincide con los servidores sobre los que funcionan nuestras propias instalaciones. Los volúmenes son mensuales y las tasas, sostenidas.

Tasa sostenida	Volumen mensual	Servidor	Notas
~1 msg/s	hasta ~1.000.000 SMS	4 vCPU, 8 GB RAM, SSD de 100 GB, todo en una sola máquina	La mayoría de los revendedores se quedan aquí su primer año
~10 msg/s	~1.000.000 a 10.000.000	8 vCPU, 16 a 32 GB RAM, SSD de 250 a 500 GB	Índice de búsqueda y base de datos, idealmente en discos propios
~50 msg/s o más	10.000.000 o más	16+ vCPU, 32 a 64 GB RAM, NVMe rápido, componentes repartidos entre nodos	Cola, base de datos, búsqueda y capa SMPP tienen cada una su propio espacio

Dos cosas de esta tabla sorprenden a la gente. La primera, lo pequeño que es el primer nivel: una plataforma multiinquilino completa, con consola web, servidor SMPP, cola, base de datos e índice de búsqueda, cabe en una máquina de 4 vCPU, porque a 1 msg/s ninguno de esos componentes está bajo presión. La segunda, que el salto al tercer nivel no tiene que ver con la CPU. Tiene que ver con la E/S: a 50 msg/s la base de datos escribe la fila de un mensaje, la actualiza cuando el operador lo confirma, la vuelve a actualizar cuando llega el acuse y la indexa para la búsqueda. Tres escrituras por mensaje a 50 msg/s son 150 escrituras por segundo, sostenidas, más las lecturas de cada panel de cliente que esté abierto. Eso es un problema de disco, y por eso NVMe y los nodos separados aparecen en la tercera fila y no antes.

La cuestión de las ráfagas: empezar en pequeño y necesitar margen

Hay un caso intermedio habitual que la tabla no recoge: usted empieza desde cero, así que su volumen mensual es mínimo, pero su primer cliente es una cadena de colegios o una tienda de comercio electrónico que lo envía todo en una sola ráfaga por la mañana y espera que llegue en cuestión de minutos. Necesita un margen de 100 a 200 msg/s mientras su tasa sostenida sigue por debajo de 1 msg/s.

La respuesta es un servidor dedicado de 4 a 8 vCPU con 32 GB de RAM. Cuesta de 50 a 100 USD al mes en los proveedores que se indican más abajo, absorbe la ráfaga porque los núcleos son suyos y la RAM mantiene en memoria la cola y el conjunto de trabajo, y le sirve hasta que el volumen sostenido, los acuses de entrega y los informes empiezan a competir por el mismo disco. Ese es el momento de subir de nivel, y suele llegar después del décimo cliente, no del primero.

El error de principiante más caro en este negocio es comprar el tercer nivel el primer día porque una hoja de cálculo decía que tendría 50 clientes. Compre el primer nivel preparado para ráfagas, vigile el disco y la cola de acuses, y suba de nivel cuando las gráficas se lo indiquen.

vCPU dedicada frente a compartida

Las listas de precios de alojamiento difuminan una distinción importante. Una instancia compartida de “4 vCPU” le da cuatro porciones de tiempo de unos núcleos que otros inquilinos también están usando; una instancia dedicada de “4 vCPU” le da cuatro núcleos que son suyos. Para un sitio web la diferencia no se nota. Para una pasarela SMS es la diferencia entre que una promoción llegue en diez minutos o en cuarenta.

La razón es la forma de la carga. El tráfico web es uniforme y tolerante; un segundo lento de vez en cuando pasa desapercibido. El tráfico SMS llega a ráfagas y mantiene estado: durante una ráfaga, la capa SMPP debe mantener alimentados sus binds con los operadores y responder a tiempo a sus latidos (heartbeats), la cola debe vaciarse y los acuses deben emparejarse con sus mensajes mientras estos siguen en la memoria activa de la base de datos. Si en ese momento un vecino está usando el núcleo compartido, el bind se detiene, la ventana del operador se llena, el operador le aplica limitación de tasa (throttling) y sus acuses se acumulan detrás de los envíos. Nada se rompe, pero todo lo que prometió al cliente sobre velocidad e informes llega ahora con retraso.

Regla práctica: vCPU compartida para la demostración y el servidor de staging, vCPU dedicada para todo lo que pague un cliente. La diferencia de precio en el primer nivel es de 20 a 40 USD al mes, menos que una hora de su tiempo explicándole a un cliente por qué el informe de ayer todavía se está actualizando.

RAM: qué vive realmente en memoria

Las necesidades de memoria son más fáciles de razonar. Hay tres cosas que conviene mantener residentes: la cola (cada mensaje aceptado pero todavía no entregado a un operador, más cada acuse todavía no emparejado), el conjunto de trabajo de la base de datos (los mensajes de los últimos días, los tarifarios, las cuentas de cliente) y la caché del índice de búsqueda. En el primer nivel, las tres juntas caben en 8 GB con espacio para el sistema operativo y la consola web. En el segundo nivel, el conjunto de trabajo crece con su historial, y de 16 a 32 GB evitan que la base de datos tenga que ir al disco para los informes que los clientes abren cada mañana.

En la práctica, la RAM no se agota por la cola, sino por los informes. Un cliente que pide “todos los mensajes a este país del último trimestre” a una base de datos que tiene que leerlo del disco convierte una consulta de dos segundos en una de dos minutos, y ralentiza a todos los demás mientras se ejecuta. Añadir RAM es la solución más barata; archivar los mensajes antiguos en un almacén de documentos, que es lo que hace el diseño separado del tercer nivel, es la solución duradera.

Disco: los acuses de entrega y el archivo son lo que crece

El disco es donde se produce el crecimiento real, y es la parte que nadie dimensiona. Cada mensaje que envía genera al menos tres registros: el propio mensaje, su acuse de entrega del operador y el asiento de facturación con el que se cobró al cliente. Añada los índices que hacen rápidos la búsqueda y los informes, y una cifra práctica de planificación es de alrededor de 1 KB por mensaje en total, antes de compresión.

En el primer nivel, 1.000.000 de mensajes al mes suponen aproximadamente 1 GB de crecimiento al mes. Un SSD de 100 GB aguanta años a ese ritmo. En el segundo nivel, 10.000.000 de mensajes al mes son 10 GB al mes, 120 GB al año, y un índice de búsqueda encima añade de un 30 a un 50 por ciento, y por eso la segunda fila indica de 250 a 500 GB y el índice de búsqueda y la base de datos van “idealmente” en discos propios: cuando comparten uno, compiten por el mismo ancho de banda de escritura.

Dos decisiones de diseño evitan que esto se convierta en un problema. La primera, un nivel de archivo: la base de datos principal conserva la ventana reciente (por ejemplo, 90 días) y los mensajes más antiguos pasan a un almacén de documentos donde siguen siendo consultables pero ya no ralentizan las tablas transaccionales. La segunda, una política de retención que usted decida de verdad: muchos operadores de pasarela conservan los acuses de entrega de 12 a 24 meses para las disputas y borran antes el cuerpo de los mensajes, y algunos mercados regulan el periodo de retención, así que confirme la norma de los países a los que envía. Una plataforma con una capa de archivo integrada, que es como está diseñada la pila de Smppcube, con MongoDB como archivo junto a MySQL como sistema de registro, convierte ambas decisiones en un ajuste y no en un proyecto.

Red y puertos

El ancho de banda no es la limitación; un mensaje ocupa unos cientos de bytes. Lo que importa es una IP pública estable, porque los operadores suelen incluir en su lista de IP permitidas la IP de su bind SMPP y no les gusta tener que actualizarla, y un puerto de entrada 2775 abierto (o el que usted elija) si sus propios clientes van a hacer bind a su servidor SMPP. Además, HTTPS para la consola y la API HTTP, y acceso saliente a los endpoints SMPP y HTTP de los operadores. Si opera en una DMZ o aislado de la red (air-gap), la pasarela solo necesita los enlaces con los operadores y la red de la consola, y esa es una de las razones por las que el autoalojamiento funciona en entornos regulados donde un panel SaaS ni siquiera se puede aprobar.

Una lista corta de proveedores con precios

Sirve cualquier proveedor que venda vCPU dedicada, almacenamiento SSD o NVMe y una IP estática, y que le permita abrir un puerto. Estos son los que vemos con más frecuencia. Un servidor dedicado de 4 a 8 vCPU y 32 GB, que cubre el primer nivel preparado para ráfagas y la CPU y la RAM del segundo nivel, suele costar de 50 a 100 USD al mes en cualquiera de los cuatro primeros; el tercer nivel, con NVMe y nodos separados, se presupuesta a medida en todos ellos.

Proveedor	Encaja en	Por qué aparece
Hetzner	Europa	Planes de vCPU dedicada y servidores físicos (bare metal) a precios bajos
Netcup	Europa	Núcleos dedicados a bajo coste; nosotros mismos usamos Netcup
DigitalOcean	Regiones en todo el mundo	Consola sencilla, precios predecibles, instantáneas (snapshots) fáciles
OVHcloud	Europa, Norteamérica	Servidores físicos disponibles cuando las máquinas virtuales se le quedan pequeñas
Alibaba Cloud	Arabia Saudí y el Golfo	Un centro de datos dentro de Arabia Saudí para la residencia de datos
Su propio hardware	Entornos aislados de la red o regulados	Solo cuotas de coubicación; la pasarela no necesita nada del exterior salvo los enlaces con los operadores

La mención “nosotros mismos usamos Netcup” está ahí porque los compradores lo preguntan; es una constatación de lo que funciona en los dos primeros niveles, no una recomendación de ignorar a los demás. Consulte las listas de precios vigentes antes de decidir. Si sus clientes están en un solo país, un proveedor con una región allí acorta el trayecto de ida y vuelta hasta los operadores y, lo que es más importante, mantiene los datos donde el regulador espera que estén.

La factura completa, con honestidad

El dimensionamiento del servidor solo tiene sentido junto al resto de la factura, y aquí es donde el modelo autoalojado se gana su nombre. Tres líneas, y solo una de ellas es nuestra:

1. La licencia, una sola vez: 6,400 USD por la plataforma, todos los canales, todas las funciones y el primer año de soporte. Esa es la página de precios en una sola cifra.
2. El servidor, cada mes: de 50 a 100 USD en los dos primeros niveles, pagados al proveedor que usted elija, en su propia cuenta, y puede trasladarlo cuando quiera.
3. Su tráfico con los operadores, a las tarifas que negocie con su propio SMSC o agregador. Nunca nos situamos en medio.

Compárelo con un panel alquilado, donde la cuota de la plataforma crece con su tráfico y el servidor es invisible porque es del proveedor: la línea del servidor es lo único que no puede abaratar creciendo, y aquí es la línea más pequeña de la página.

Copias de seguridad, monitoreo y las partes aburridas

Un servidor no es un plan. Antes de que el primer cliente entre en producción, deberían existir tres cosas, y deberían estar probadas:

• Una copia de seguridad nocturna que haya restaurado al menos una vez. El volcado de la base de datos más el directorio de configuración, copiados fuera de la máquina (la instantánea del proveedor es cómoda, pero una instantánea en la misma cuenta que el servidor no es una copia de seguridad frente a un bloqueo de esa cuenta). Pruebe la restauración en la máquina de staging; una copia de seguridad que nadie ha restaurado es solo una esperanza.
• Alertas de disco y de cola. Bastan dos umbrales: disco por encima del 80 por ciento y cola de acuses con más de 15 minutos de antigüedad. El primero le indica que archive o amplíe; el segundo le avisa de que un bind con un operador no está sano antes de que se lo diga un cliente.
• Un servidor de staging. El VPS compartido más barato que encuentre, con la misma versión, donde se prueban primero las actualizaciones y los nuevos tarifarios. Cuesta lo que un café al mes; su valor es cada actualización que no tendrá que revertir en la máquina de producción mientras los clientes están enviando.

Cuándo no necesita nada de esto

Si envía unos pocos miles de mensajes al mes desde una sola aplicación y no tiene clientes propios, no necesita ningún servidor de pasarela; una API HTTP de cualquier proveedor, llamada desde su aplicación, es la medida justa. El dimensionamiento de esta guía es para quienes venden mensajería a terceros: revendedores, agregadores, operadores, o una empresa que gestiona la mensajería de muchos equipos internos. En ese punto, el servidor es la parte menos costosa del negocio, y saber en qué nivel está, y qué le hará pasar al siguiente, es casi todo lo que “requisitos” ha significado siempre.