Cómo construir sistemas en tiempo real: chat, notificaciones y actualizaciones en vivo
Las funciones en tiempo real parecen sencillas para los usuarios y son sorprendentemente difíciles de construir bien. Así es como construyo chat, notificaciones push y actualizaciones en vivo fiables, y la arquitectura que evita que se caigan.
Shayan Jamil·24 de mayo de 2026·7 min de lectura
Las funciones en tiempo real son engañosas. Para un usuario, que un mensaje de chat aparezca al instante o que salte una notificación parece obvio y simple: "claro que funciona así". Entre bastidores, hacerlo fiable es una de las cosas más complicadas del desarrollo de aplicaciones. Muchos productos tienen funciones en tiempo real que van de maravilla en una demo y empiezan a fallar en cuanto tienen usuarios reales.
Este artículo trata sobre cómo construyo funciones en tiempo real que realmente aguantan: chat en vivo, notificaciones push y paneles que se actualizan a medida que ocurren las cosas. Si tu producto necesita alguna de ellas, vale la pena entender lo que implica de verdad.
Qué se considera "tiempo real"
Las funciones en tiempo real son las partes de una app donde las cosas ocurren en vivo, sin que el usuario tenga que recargar:
- Chat y mensajería: los mensajes aparecen al instante para todos los participantes de la conversación
- Notificaciones: alertas dentro de la app y notificaciones push que llegan cuando ocurren los eventos
- Actualizaciones en vivo: paneles, feeds o estados que cambian ante tus ojos (piensa en el seguimiento de un pedido en directo o en un panel de ventas que va subiendo)
- Presencia: saber quién está conectado y quién está escribiendo
Estas funciones hacen que los productos se sientan vivos y ágiles. También son donde la ingeniería descuidada se nota antes.
El problema de negocio: el tiempo real es donde muere el "en mi máquina funciona"
La historia habitual: un desarrollador construye el chat, funciona perfectamente cuando lo prueba con dos pestañas del navegador y todos lo dan por bueno. Luego sale a producción y, con más usuarios, empieza a perder mensajes, a mostrarlos desordenados, a enviar notificaciones duplicadas o a desmoronarse en silencio cuando el servidor se reinicia.
El motivo es que los sistemas en tiempo real tienen que lidiar con realidades duras que una demo con dos pestañas nunca expone: muchas conexiones simultáneas, usuarios en redes móviles inestables que se desconectan y reconectan constantemente, servidores que necesitan reiniciarse sin desconectar a todo el mundo y la necesidad de entregar un mensaje incluso cuando la app del destinatario está cerrada. Construir para esas realidades desde el principio es la diferencia entre una función que encanta y una que te deja en evidencia.
Cómo construyo bien las funciones en tiempo real
WebSockets para la conexión en vivo
Las peticiones web normales son de ida y vuelta: la app pregunta, el servidor responde y la conexión se cierra. El tiempo real necesita un canal abierto y bidireccional para que el servidor pueda enviar datos a la app en el instante en que algo ocurre. Eso es lo que ofrecen los WebSockets (suelo usar Socket.io para ello). Son la columna vertebral del chat y de las actualizaciones en vivo.
Una forma de escalar más allá de un servidor
Aquí hay un punto sutil pero crítico. Cuando tienes más de un servidor (y cualquier app en crecimiento lo tendrá), un usuario conectado al servidor A necesita recibir un mensaje enviado a través del servidor B. Sin una capa de coordinación compartida, el tiempo real se rompe en silencio a medida que escalas. Uso una capa compartida (normalmente Redis) para que los mensajes lleguen a los usuarios correctos sin importar a qué servidor estén conectados. Es de esas cosas que son invisibles hasta que faltan.
Colas en segundo plano para la entrega
Enviar notificaciones, sobre todo notificaciones push a miles de dispositivos, no debería ocurrir dentro de la petición de un usuario. Paso este trabajo a colas de tareas en segundo plano (a menudo respaldadas por Redis), de modo que sea fiable, se pueda reintentar y no ralentice nada. Si una notificación no se envía, se puede reintentar en lugar de perderse sin dejar rastro.
Notificaciones push que realmente llegan
El tiempo real dentro de la app solo llega a los usuarios que la tienen abierta. Las notificaciones push (a través de servicios como Firebase Cloud Messaging) llegan a los usuarios cuando la app está cerrada, y es lo que los hace volver. Hacer bien las notificaciones push en iOS y Android, con una gestión correcta de los tokens de dispositivo y los enlaces profundos, es un trabajo cuidadoso en sí mismo.
Diseñar pensando en las desconexiones
Los usuarios móviles pierden la conexión constantemente. Un buen sistema en tiempo real gestiona la reconexión con elegancia y se asegura de que el usuario se ponga al día con lo que se perdió mientras estaba fuera, en lugar de perder mensajes en silencio.
La pregunta de arquitectura que importa
"¿Qué pasa cuando tienes más de un servidor?" Si el tiempo real se construyó suponiendo un único servidor, se romperá en cuanto escales. Diseñar para varios servidores desde el principio, con una capa de coordinación compartida, es lo que separa un sistema real de una demo.
Un ejemplo realista
El tiempo real ha sido clave en buena parte de mi trabajo. En una plataforma SaaS multi-tenant, construí chat y notificaciones en tiempo real con WebSockets (Socket.io), una cola de tareas respaldada por Redis para el trabajo que no debía bloquear las peticiones y Firebase para las notificaciones push, con los archivos multimedia gestionados mediante almacenamiento en la nube. En un backend de interacción con fans y venta de entradas, las notificaciones en tiempo real se construyeron sobre el mismo tipo de stack: WebSockets, Redis y entrega push.
La razón por la que aguantaron es que se diseñaron para las realidades de producción, no para la demo. La capa de Redis hacía que los mensajes llegaran a los usuarios a través de varios servidores. La cola de tareas hacía que el envío de notificaciones fuera fiable y se pudiera reintentar. Las notificaciones push hacían que los usuarios volvieran incluso con la app cerrada. Nada de eso es visible para quien usa la app, y precisamente de eso se trata. La buena infraestructura en tiempo real se nota, no se ve.
Errores comunes con los sistemas en tiempo real
- Suponer un único servidor. El tiempo real construido así se rompe en cuanto escalas horizontalmente.
- Entregar las notificaciones dentro de las peticiones en lugar de en tareas en segundo plano, lo que lo vuelve todo lento y frágil.
- Ignorar la reconexión. Los usuarios móviles se desconectan constantemente; los mensajes perdidos durante una caída no deberían desaparecer.
- Olvidarse de las notificaciones push, de modo que la función solo llega a quien casualmente tiene la app abierta.
- No tener idempotencia, lo que provoca mensajes y notificaciones duplicados.
- Probar solo con dos pestañas. La carga real y las redes reales no se parecen en nada a una demo tranquila.
Cómo abordo el trabajo en tiempo real
- Uso WebSockets para el canal en vivo, con una librería probada en batalla.
- Diseño para varios servidores desde el primer día con una capa de coordinación compartida.
- Paso el trabajo de entrega a colas en segundo plano para que sea fiable y se pueda reintentar.
- Gestiono bien las notificaciones push en iOS y Android.
- Planifico la desconexión y la puesta al día para que nada se pierda en silencio.
- Pruebo en condiciones realistas, no solo con dos pestañas del navegador.
Las funciones en tiempo real se apoyan en un backend sólido, así que cómo construir un backend escalable para un producto SaaS es un complemento natural. Y como las notificaciones push son una parte importante de esto, qué hace que una app móvil esté lista para producción trata la parte móvil con más profundidad.
¿Necesitas funciones en tiempo real fiables?
Si tu producto necesita chat, notificaciones o actualizaciones en vivo que realmente aguanten con usuarios reales, no solo en una demo, ese es exactamente el tipo de trabajo que hago. Construyo sistemas en tiempo real diseñados para producción desde el principio, con la arquitectura que los mantiene fiables a medida que creces.
Echa un vistazo a mis proyectos y luego ponte en contacto para contarme qué estás construyendo. Con gusto hablamos de lo que hará falta para que se sienta instantáneo y siga siendo fiable.