Arquitectura Detallada de Aletheia

Aletheia está diseñada como un ecosistema de microservicios contenerizados, siguiendo el patrón de Arquitectura Hexagonal. Este enfoque asegura una alta cohesión, un bajo acoplamiento y una excelente escalabilidad, permitiendo que cada componente evolucione de forma independiente.

(Opcional pero recomendado: crea un diagrama simple de la arquitectura con una herramienta como diagrams.net, súbelo a Imgur o a una issue de GitHub y enlaza la imagen aquí.)

Los 5 Servicios Principales y su Interacción

El sistema se compone de cinco servicios Docker que se comunican a través de una red interna definida por docker-compose. A continuación, se detalla la responsabilidad y el flujo de cada uno.

1. aletheia_dashboard (La Cabina de Mando del Investigador)

• Tecnología: Streamlit
• Responsabilidad: Proporcionar la interfaz de usuario. Es un cliente stateless que se comunica exclusivamente con el servicio de API. No contiene ninguna lógica de negocio, su único propósito es presentar datos y recoger la entrada del usuario.
• Flujo de Interacción:
  1. El usuario interactúa con los widgets de la interfaz (sliders, botones).
  2. Al enviar un trabajo, se realiza una petición HTTP POST a aletheia_api.
  3. Para actualizar el estado, se realizan peticiones HTTP GET a aletheia_api para obtener la información más reciente de los trabajos.

2. aletheia_api (El Pórtico de Entrada)

• Tecnología: FastAPI, Pydantic, SQLAlchemy
• Responsabilidad: Actuar como el punto de entrada seguro y validado al sistema. Es la única puerta de entrada para cualquier cliente, gestionando las solicitudes y delegando el trabajo pesado.
• Flujo de Interacción:
  1. Recibe una petición del dashboard u otro cliente programático.
  2. Valida la estructura y los tipos de datos de la solicitud usando los modelos de Pydantic.
  3. Crea un registro JobDB en la base de datos con estado "pending" a través de una sesión de SQLAlchemy.
  4. Envía una tarea (el job_id y los parámetros necesarios) a la cola de mensajes de Redis.
  5. Devuelve una respuesta 202 Accepted inmediatamente al cliente, confirmando que el trabajo ha sido aceptado pero sin esperar a que se complete.

3. aletheia_redis (El Sistema Nervioso Central)

• Tecnología: Redis
• Responsabilidad: Servir como un message broker de alta velocidad y baja latencia. Su función es desacoplar completamente la API (que debe ser rápida) de los workers (que pueden ser lentos).
• Flujo de Interacción:
  1. Almacena los mensajes de tareas enviados por la API en una cola gestionada por Celery.
  2. Mantiene los mensajes hasta que un worker esté disponible para procesarlos.

4. aletheia_db (La Biblioteca de la Verdad)

• Tecnología: PostgreSQL
• Responsabilidad: Ser la única fuente de verdad y memoria a largo plazo del sistema. Garantiza la durabilidad de los datos.
• Flujo de Interacción:
  1. Almacena los Jobs creados por la API.
  2. Almacena los Hits (descubrimientos) encontrados y guardados por los workers.
  3. Es consultada por la API para devolver el estado y los resultados de un trabajo al cliente.

5. aletheia_worker (El Motor de Cómputo)

• Tecnología: Celery, scikit-optimize
• Responsabilidad: Ejecutar el trabajo pesado y la lógica de IA. Es el único componente que consume CPU de forma intensiva y está diseñado para ser escalado horizontalmente.
• Flujo de Interacción:
  1. Escucha continuamente en la cola de Redis por nuevos trabajos.
  2. Cuando recoge un job_id, consulta la base de datos para obtener los parámetros completos del trabajo.
  3. Actualiza el estado del trabajo en la base de datos a "processing".
  4. Invoca al IntelligentSearchUseCase, que contiene el "cerebro" de la IA y el bucle de optimización.
  5. A medida que la IA encuentra "hits" valiosos, el worker los guarda en la base de datos, asociándolos al job_id.
  6. Una vez que el presupuesto de búsqueda de la IA se agota, actualiza el estado final del trabajo en la base de datos a "completed".