Notificaciones en Tiempo Real
Que el usuario se entere en el momento, sin recargar la página.
El problema
El ERP no avisaba nada en el momento. Si alguien registraba un pago o una venta, el resto del equipo se enteraba recién cuando recargaba la página, y muchos ni sabían que tenían que recargar. Eso se traducía en gente trabajando con datos viejos: preguntaban "¿ya se pagó esto?" cuando ya estaba pagado, repetían acciones que otro ya había hecho, o pensaban que el sistema se había quedado pegado. El clásico era el usuario apretando F5 cada dos minutos por las dudas. Un sistema que se siente muerto genera desconfianza, y esa desconfianza cuesta revertirla.
La solución
El punto de partida era claro: no quería que el usuario tuviera que recargar para enterarse. Descarté el polling puro del navegador —caro y con latencia— y me fui a WebSocket, que mantiene la conexión abierta y empuja el evento apenas ocurre. La duda real vino después: ¿y si el servicio que empuja se cae justo cuando pasa algo importante? Ahí decidí no confiar todo al push, y sumé un poller que cada pocos segundos revisa lo que pudo perderse. Con eso el push da la velocidad y el polling da la garantía. Para no acoplarlo a Laravel, en vez de compartir la sesión hice que el backend firme un token HMAC que el servicio en Go valida por su cuenta: dos servicios independientes que igual confían entre sí. Y el aislamiento por empresa lo puse en el hub, no en cada mensaje, para que un usuario nunca reciba lo que no es suyo.
Decisiones técnicas
WebSocket + polling, no solo push
El push da latencia baja; el polling de respaldo garantiza entrega si el push falla. Robustez sin sacrificar velocidad.
Token HMAC en vez de compartir sesión
El Go valida al cliente sin acceso a la sesión de Laravel: dos servicios desacoplados que igual confían entre sí.
Un canal por empresa
Cada usuario recibe solo lo suyo; el aislamiento vive en el hub, no en cada mensaje.
En vivo
El realtime en acción: conexiones por empresa, un envío de prueba y un caso real.