Mi sistema de reservas ya era fiable y resistente, pero tenía un fallo clave: era silencioso. Si otro usuario reservaba un artículo, el inventario se actualizaba correctamente en el backend, pero quienes estaban viendo la página seguían viendo un número obsoleto. Para ofrecer una experiencia realmente dinámica, necesitaba enviar actualizaciones a los usuarios en el instante en que ocurrían. Ese era el trabajo perfecto para WebSockets.
Preparando el terreno: más allá de las solicitudes simples. HTTP tradicional es como enviar una carta: haces una petición y recibes una respuesta. Para un conteo de inventario en vivo, necesitamos una llamada telefónica: una conexión persistente y bidireccional en la que el servidor pueda hablar con el cliente en cualquier momento.
Eso es lo que aporta WebSocket, estableciendo una conexión estable sobre TCP tras un apretón de manos de tipo Upgrade. Elegí la librería Socket.IO porque su motor Engine.IO es muy inteligente: intenta usar WebSocket de alta velocidad y, si la red del usuario lo bloquea, retrocede automáticamente a alternativas fiables como HTTP Long-Polling, asegurando que nadie se quede atrás.
Versión 1: el pregonero del pueblo. La primera implementación fue directa. Usé Pub/Sub de Redis para crear un canal de comunicación. Cuando un proceso worker de compra actualizaba el inventario, publicaba el nuevo stock. Mi API principal estaba suscrita al canal y, al recibir el mensaje, emitía la actualización a todos los usuarios conectados con io.emit.
Funcionó, pero con un efecto colateral ruidoso. Un usuario viendo una camiseta recibía en tiempo real las reservas de unas zapatillas que no le interesaban. Como un pregonero gritando todas las noticias a todo el pueblo. Era ineficiente y una mala experiencia de usuario.
Versión 2: la sala privada. La solución fue tratar cada página de producto como una sala VIP privada. En lugar de difundir a todos, el servidor debía enviar actualizaciones solo a quienes estuvieran viendo ese producto concreto. Aquí la característica Rooms de Socket.IO brilló.
El nuevo flujo es elegante: cuando el usuario abre la página de un producto, el frontend se conecta y avisa que está visualizando, por ejemplo, product-1. El servidor añade ese socket a la sala product-1. Cuando llega una actualización de inventario para product-1 por Pub/Sub de Redis, el servidor ya no emite a todos, solo a los clientes dentro de la sala product-1.
Este enfoque dirigido es muy eficiente y ofrece una experiencia fluida y relevante. El usuario ve al instante las actualizaciones del producto que le importa y nada más. En nuestro caso, redujimos mensajes innecesarios un 92 por ciento y el consumo de ancho de banda en páginas de producto un 75 por ciento. Así, la aplicación pasó de ser una secuencia silenciosa de peticiones separadas a un sistema vivo, donde las acciones del backend se reflejan al instante en el frontend.
Puedes consultar el código completo en GitHub: repositorio de ejemplo
En Q2BSTUDIO diseñamos y construimos soluciones de tiempo real como esta, integradas con inventarios, catálogos y pasarelas de pago, combinando arquitectura escalable, seguridad y analítica. Somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con un fuerte foco en inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi. Si buscas un socio para crear tu sistema de inventario en vivo y optimizar la experiencia digital, descubre nuestro desarrollo de aplicaciones a medida y cómo lo alineamos con tus objetivos.
Para desplegar y escalar conexiones WebSocket de forma fiable, aprovechamos arquitecturas serverless, balanceadores y cachés globales, todo ello protegido con buenas prácticas de ciberseguridad y observabilidad. Podemos ayudarte a diseñar una plataforma multizona con CDN, colas y Pub/Sub que minimice la latencia y maximice la resiliencia, ya sea en AWS o Azure. Conoce nuestros servicios cloud AWS y Azure y lleva tu inventario del modo atraso al modo en vivo.