Una aplicación de chat con IA es una interfaz de chat de texto en la que el usuario escribe un mensaje, la aplicación lo envía a un servicio capaz de invocar un modelo de IA y, posteriormente, muestra la respuesta del modelo al usuario.
En muchos productos, la respuesta llega como un flujo de datos (stream); de este modo, el usuario ve cómo aparecen los tokens progresivamente en lugar de tener que esperar a recibir la respuesta completa.
Para simplificar el planteamiento, imaginemos un escenario inicial con un pequeño equipo interno que utiliza una aplicación web; esta se comunica con un único servicio backend, el cual a su vez invoca a un proveedor de modelos.
Cuando se utiliza un solo servidor, el flujo funciona como un ciclo. El cliente envía el mensaje del usuario a un único servidor de API; este carga la conversación para disponer de contexto, invoca al proveedor del modelo y, finalmente, devuelve la respuesta del asistente al cliente.
El almacenamiento de la conversación es importante incluso en esta configuración básica, ya que actualizar la página no debería borrar el historial del chat. El servidor de API guarda de forma persistente tanto los mensajes del usuario como los del asistente, y utiliza dicha información almacenada para dar continuidad a la conversación en el siguiente turno.
A continuación, se presenta el turno de chat único que estamos desarrollando como base del sistema.
El diagrama contempla cuatro funciones. El cliente recopila la entrada y renderiza el flujo de datos; el servidor de API gestiona el ciclo de vida de la solicitud; el almacén de conversaciones conserva los mensajes para que el hilo persista tras una actualización de la página; y la API del modelo genera los tokens del asistente que el servidor transmite de vuelta al cliente.
El alcance funcional se limita a un chat de texto plano. No hay herramientas, imágenes ni carga de archivos, por lo que las únicas tareas por turno son almacenar mensajes, preparar el contexto y llamar al modelo.
Consideremos ahora una cifra que somete a presión a un único servidor. Con 2.000 usuarios simultáneos realizando 2 turnos por minuto, el backend debe gestionar aproximadamente turnos de usuario por segundo, lo que se traduce en un volumen equivalente de llamadas paralelas al modelo.
Esa cifra genera dos indicadores no funcionales que condicionarán el resto del diseño. La latencia cobra relevancia, ya que las llamadas al modelo representan la mayor parte del tiempo de procesamiento integral (end-to-end), y el coste se vuelve un factor crítico, dado que el sistema paga por cada solicitud y por cada token generado.
Incluso antes de escalar, la arquitectura base se divide claramente en componentes reutilizables, cada uno con una responsabilidad específica.