Escalar una plataforma de comercio autoalojada: hoja de ruta de servidores de 100 a 100.000 pedidos al día

Toda plataforma de comercio autoalojada empieza igual: un servidor, una base de datos y una persona que sabe dónde está cada cosa. Es la forma correcta de empezar. Es barato, sencillo y lo bastante rápido para los primeros mil clientes.

El problema llega cuando el crecimiento avanza más rápido que la arquitectura. Una venta flash duplica el tráfico una tarde. Una integración con la mensajería reintenta cada pocos segundos. Un informe financiero recorre dos años de pedidos en plena hora punta del mediodía. De repente el checkout va lento y nadie sabe por qué.

Esta guía es la hoja de ruta de escalado que uso al planificar la infraestructura de sistemas de comercio y ERP. Recorre cuatro etapas, desde unos 100 pedidos al día hasta 100.000 y más. Para cada etapa explica qué añadir, qué medir y, lo más importante, qué se rompe primero, para que cambies la arquitectura cuando te lo diga un número y no cuando te lo diga un cliente.

Primer principio: mide antes de escalar

Escalar es caro y cada componente nuevo es otra cosa que puede fallar. Antes de añadir servidores, asegúrate de ver estos cinco números en un panel:

• Tiempo de respuesta p95 de la portada, una ficha de producto, el carrito y el checkout. Las medias esconden las peticiones lentas que hacen perder ventas.
• Carga de la base de datos: conexiones activas, consultas lentas (todo lo que pase de 100 ms) y tasa de aciertos de caché.
• Profundidad y antigüedad de las colas: cuántos trabajos esperan y cuánto lleva esperando el más antiguo.
• Memoria y swap en cada servidor, además de los procesos terminados por falta de memoria en el log del kernel.
• Tasa de errores: respuestas 5xx por minuto y trabajos fallidos por hora.

Si no puedes ver estos números, el primer proyecto de escalado es la observabilidad. Un servidor que no ves es un servidor que comprarás de más.

Etapa 1 — Todo en una máquina (hasta unos 1.000 pedidos al día)

Un único servidor virtual con 4 vCPU, 8 GB de RAM y almacenamiento SSD rápido mueve un volumen de negocio sorprendente. Los contenedores lo mantienen ordenado: web (PHP-FPM detrás de nginx), PostgreSQL, Redis, un worker de colas y un planificador.

Qué hacer bien en esta etapa

• OPcache activado, con precarga. PHP compila cada archivo una vez y lo mantiene en memoria. Solo esto suele reducir a la mitad los tiempos de respuesta.
• Nada de trabajo en el arranque de los proveedores. Todo lo que se ejecuta en cada petición (leer ajustes, construir menús) debe ir en caché. Diez milisegundos por petición se convierten en un núcleo de CPU a escala.
• Trabajos en segundo plano para lo lento. Correos, reservas con la mensajería, conversiones de imágenes y facturas PDF van a la cola, nunca dentro de la petición del checkout.
• Copias fuera del servidor, y probadas. Un volcado nocturno de la base de datos a almacenamiento de objetos y una prueba de restauración mensual. Una copia sin probar es una esperanza, no una copia.

Qué se rompe primero

La memoria. Un informe pesado, una importación o un lote de imágenes compiten con el checkout por la RAM. Lo verás como páginas lentas al azar y, al final, el kernel matando un proceso. El planificador es una víctima habitual: dale su propio límite de memoria (512 MB es un mínimo razonable) y ejecuta un único proceso planificador de larga duración en lugar de lanzar uno nuevo cada minuto.

Etapa 2 — Separar por funciones (unos 1.000 a 10.000 pedidos al día)

El siguiente paso no es "el mismo servidor, pero más grande". Es separar funciones para que dejen de competir entre sí.

Función	Por qué se separa	Tamaño típico
Servidor de base de datos	Su propio disco y memoria para caché; sin vecinos ruidosos.	4–8 vCPU, 16–32 GB de RAM, NVMe
Servidor Redis	Sesiones, caché y colas siguen rápidas bajo carga.	2 vCPU, 4–8 GB de RAM
Nodos web	Trabajo PHP intensivo en CPU, escalado de forma independiente.	2–4 vCPU cada uno
Workers de colas	Grupos separados por cola, para que los correos nunca retrasen los pagos.	2 vCPU por grupo

Guarda en caché las páginas que ven los visitantes

La mayor parte del tráfico de una tienda es anónimo: gente que mira productos y categorías. Esas páginas pueden guardarse unos minutos como HTML completo en la aplicación y en la CDN. Dos reglas evitan errores dolorosos:

• La clave de caché debe incluir el dominio. Si tu tienda responde en dos dominios, una clave sin dominio sirve los enlaces y scripts de uno al otro.
• Nunca guardes en caché nada personal. El contador del carrito, los precios para clientes registrados y las páginas de cuenta se pintan después del esqueleto en caché, o no se cachean.

Qué se rompe primero

Las conexiones a la base de datos y las consultas lentas. Cada worker de PHP abre su propia conexión. Cuarenta workers en dos nodos web más los de colas pueden superar el número de conexiones cómodo para PostgreSQL. A la vez, un índice que falta convierte una consulta de 5 ms en una de 900 ms cuando la tabla supera el millón de filas. Revisa el log de consultas lentas cada semana.

Etapa 3 — Escalar horizontalmente (unos 10.000 a 50.000 pedidos al día)

Ahora ejecutas varios nodos web idénticos detrás de un balanceador. El sistema debe ser sin estado en la capa web: sesiones en Redis, archivos subidos en almacenamiento de objetos y nada importante en el disco local de un nodo.

Los componentes que importan en esta etapa

• Pool de conexiones (PgBouncer). Cientos de conexiones de la aplicación comparten unas pocas decenas de conexiones reales. Suele ser la mayor mejora de estabilidad.
• Una réplica de lectura para informes. Paneles, exportaciones y analítica leen de la réplica, así un informe pesado nunca frena el checkout.
• Almacenamiento de objetos para medios y copias. S3 o un servicio compatible como Cloudflare R2, servido a través de la CDN. Los nodos web dejan de servir imágenes.
• Un renderizador SSR separado. El renderizado en servidor hace las páginas rápidas e indexables, pero es una carga distinta a PHP. Escálalo aparte.
• Supervisión de colas. Un panel (Laravel Horizon, por ejemplo) que muestre rendimiento, fallos y tiempo de espera por cola, con alertas.

Qué se rompe primero

Las avalanchas de caché y las filas calientes. Cuando caduca una entrada de caché muy usada, cientos de peticiones intentan reconstruirla a la vez. Usa bloqueos o "stale-while-revalidate" para que una petición reconstruya mientras las demás sirven el valor anterior. Por otro lado, una fila que todos actualizan —el contador de stock de un producto en venta flash, un número de secuencia— se convierte en una cola de transacciones en espera. Mantén esas actualizaciones cortas y atómicas.

Etapa 4 — Una flota (más de 50.000 pedidos al día)

A este tamaño, los patrones técnicos son conocidos. Lo que cambia es la disciplina a su alrededor.

• Colas particionadas, para que pagos, notificaciones, indexación de búsqueda y trabajos de IA tengan capacidad dedicada.
• Búsqueda y analítica en motores propios, alimentados por eventos en lugar de volcados nocturnos.
• Almacenamiento de archivo para el histórico. Pedidos antiguos, logs y auditorías pasan a un almacenamiento más barato sin dejar de ser consultables.
• Edge multirregión para recursos estáticos y páginas en caché, cerca de los clientes.
• Runbooks y guardias. Cada alerta tiene una primera respuesta escrita. Las peores caídas que he visto no se debieron a falta de servidores, sino a que nadie sabía qué hacer a las 3 de la madrugada.

Desplegar sin caídas: azul/verde

Una tienda que se desconecta en cada versión enseña al equipo a publicar menos, lo que hace cada publicación más arriesgada. El despliegue azul/verde rompe ese círculo.

1. Compila una vez. Una imagen por commit, probada en CI y promovida sin cambios de staging a producción.
2. Arranca verde junto a los contenedores azules en vivo.
3. Migra solo añadiendo. Añade columnas y tablas; nunca renombres ni borres en la misma versión. El código antiguo debe seguir funcionando con el esquema nuevo.
4. Calienta y comprueba. Cachea configuración y rutas, llama al endpoint de salud y ejecuta una prueba rápida.
5. Conmuta el upstream de la pasarela con una recarga, no un reinicio, para no cortar ninguna conexión.
6. Mantén azul en marcha para revertir al instante. Elimina las columnas antiguas en una versión posterior, cuando nada las lea.

Lección aprendida a golpes: borrar la caché o los archivos compilados de la versión en vivo mientras se prepara la nueva romperá algunas peticiones en cada despliegue. Prepara la nueva versión en su propio directorio y limpia la caché de la aplicación una sola vez, justo después de conmutar.

Copias de seguridad, RPO y RTO en palabras sencillas

Dos números definen tu estrategia de copias, y debe elegirlos el negocio, no el departamento de sistemas:

• RPO (objetivo de punto de recuperación): cuántos datos puedes permitirte perder. Una copia nocturna supone hasta 24 horas de pedidos.
• RTO (objetivo de tiempo de recuperación): cuánto tiempo puedes estar sin servicio mientras restauras.

Etapa	RPO razonable	RTO razonable	Cómo
1	24 horas	4 horas	Volcado nocturno y archivos a almacenamiento de objetos
2	1 hora	1 hora	Instantáneas cada hora, restauración automatizada
3–4	Minutos	Menos de 30 minutos	Archivado continuo de WAL, réplica en espera

Elijas lo que elijas, programa una prueba de restauración. En StoreConsole, el módulo de copias hace instantáneas programadas de la base de datos y los archivos, revisa la salud del disco, aplica la retención y restaura con un clic. El breve recorrido de abajo lo muestra.

Cinco trampas que veo una y otra vez

1. Un 404 cacheado en la CDN. Si subes una imagen después de que una página ya la haya pedido, la CDN puede servir "no encontrado" durante horas. Escribe primero los archivos y enlaza después.
2. Pruebas que pasan en una base de datos y fallan en otra. SQLite en pruebas y PostgreSQL en producción no coinciden en búsquedas sensibles a mayúsculas, comparaciones de tipos ni cambios de enum. Ejecuta al menos un trabajo de CI con el motor de producción.
3. Compilaciones pesadas en el servidor de producción. Dos compilaciones de recursos a la vez pueden agotar la memoria y tumbar la tienda. Compila en CI y despliega imágenes.
4. Procesos en segundo plano lanzados con un simple "&". Mueren con la sesión. Usa un supervisor o el runtime de contenedores.
5. Herramientas de depuración activas en producción. Los listeners de consultas y los perfiladores añaden trabajo a cada petición, y un monitor olvidado puede consumir una CPU durante semanas sin que nadie lo note.

Una lista de capacidad que puedes usar hoy

• Checkout p95 por debajo de 800 ms en tu hora de más actividad.
• CPU de la base de datos por debajo del 60 % en el pico; ninguna consulta de más de 100 ms en la ruta del checkout.
• El trabajo más antiguo en las colas de pagos y notificaciones, por debajo de 60 segundos.
• Al menos un 30 % de memoria libre en cada servidor en el pico; cero procesos terminados por memoria la última semana.
• Última prueba de restauración hace menos de 30 días.
• Cada versión se puede desplegar y revertir sin caídas.

Si estás dimensionando el hardware para StoreConsole, la página de requisitos del sistema recoge los tamaños recomendados por etapa y la documentación cubre Docker, colas y el planificador.

Ideas clave

• Escala cuando una métrica te lo diga: latencia p95, carga de la base de datos, antigüedad de las colas, memoria, tasa de errores.
• La etapa 1 es una máquina bien ajustada. La 2 separa funciones. La 3 escala horizontalmente con pools, réplicas y almacenamiento de objetos. La 4 es cuestión de disciplina.
• Mantén el trabajo lento fuera de la ruta de la petición; un comprador nunca debería esperar a una cola.
• Despliega en azul/verde con migraciones que solo añaden y ten la versión anterior lista para revertir.
• Deja que el negocio elija RPO y RTO, y prueba las restauraciones con un calendario.

Anichur Rahaman es arquitecto de software y creador de StoreConsole. Diseña sistemas de comercio y ERP para empresas en crecimiento, centrado en la arquitectura orientada a eventos, la integridad de los datos y la operación autoalojada.