TRAX / La Centralita
ERP modular y reservaciones: datos operativos, roles, precios, disponibilidad y experiencia de pasajero dentro de un mismo sistema.
Ver proyecto →Criterio antes que stack
La arquitectura correcta depende de lo que una operación necesita conservar, medir y controlar.
Un sistema de reservaciones, una plataforma conversacional, un producto de publicación social y un motor multimedia no tienen el mismo perfil de carga ni los mismos riesgos. Pueden compartir capacidades, pero no deberían forzarse a vivir bajo una única forma de ejecución.
Primero definimos usuarios, datos, permisos, estados, integraciones, excepciones y consecuencias. Después elegimos qué debe resolverse con interfaz, API, motor de reglas, modelo de lenguaje, cola, worker, almacenamiento o intervención humana.
La arquitectura no empieza con “qué framework usamos”. Empieza con “qué no puede perder la operación”.
Reutilización sin uniformar
No reconstruimos las mismas bases en cada producto.
Nuestros productos comparten patrones y componentes para capacidades recurrentes. Esa base permite concentrar más ingeniería en las reglas, datos, experiencia e integraciones particulares de cada operación.
- Identidad y acceso
- Usuarios, autenticación, sesiones y relaciones con organizaciones.
- Multi-tenancy
- Separación lógica por empresa u organización y validación de contexto en cada operación.
- Roles y permisos
- Acciones visibles y autorizadas según usuario, responsabilidad y contexto.
- Almacenamiento
- Patrones para documentos, imágenes, video, exports y activos privados o públicos.
- Procesamiento asíncrono
- Jobs, colas, reintentos y workers para tareas que no deberían bloquear una petición web.
- Integraciones
- Interfaces y conectores para servicios externos, APIs, webhooks, correo, mensajería y pagos cuando aplica.
- Observabilidad
- Errores, logs, métricas, trazas y estados suficientes para localizar fallas y medir comportamiento.
“Reutilizamos infraestructura. No reutilizamos el problema.”
Dos tipos de problema, dos tipos de control
Los modelos interpretan. Los motores controlan.
Un modelo de lenguaje puede interpretar intención, resumir contexto, extraer información o trabajar con lenguaje natural. Esa flexibilidad es útil precisamente porque la entrada no siempre llega de una forma predecible.
Pero permisos, estados, cálculos, elegibilidad, transiciones, límites o reglas de negocio necesitan respuestas reproducibles. Ahí utilizamos lógica determinista, motores de reglas o máquinas de estados.
Fórmula
Modelo para interpretar + motor para validar + software para registrar + persona para resolver excepciones.
Ejemplo
En desarrollos conversacionales verticales, la conversación puede sentirse flexible mientras el proceso conserva reglas, matching, scoring, estados y controles auditables.
Arquitectura SaaS
Una plataforma compartida no significa datos compartidos.
Cuando un producto atiende a varias organizaciones, el tenant forma parte del modelo de seguridad y del modelo de datos. El contexto de organización debe validarse en aplicación y persistencia, no inferirse únicamente desde la interfaz.
- Aislamiento
- Cada organización opera dentro de un contexto identificado y separado.
- Configuración
- Reglas, branding, límites o comportamiento pueden variar por organización sin duplicar todo el producto.
- Permisos
- Un usuario ve y ejecuta únicamente las acciones permitidas para su rol y tenant.
- Trazabilidad
- Las acciones relevantes conservan contexto suficiente para saber quién, dónde y bajo qué organización ocurrieron.
El multi-tenancy no se trata sólo de ahorrar infraestructura. Se trata de construir una frontera explícita entre organizaciones.
Jobs · Colas · Workers
Una tarea larga necesita estado, reintentos y una forma de recuperarse.
Procesar campañas, publicar contenido, ejecutar análisis, generar media, recibir webhooks o llamar a proveedores de IA puede tardar, fallar o alcanzar límites externos. En esos casos separamos la interfaz del trabajo de fondo.
Recorrido de un trabajo de fondo
- 01Web / API
- 02Cola
- 03Worker
- 04Proveedor / Proceso
- 05Estado / resultado
- Idempotencia
- Repetir un job no debería duplicar una acción crítica.
- Reintentos
- Las fallas temporales siguen una política definida en lugar de perder el trabajo silenciosamente.
- Backoff y límites
- El sistema espera y reduce presión cuando un proveedor falla o limita solicitudes.
- Dead-letter / revisión
- Los trabajos que agotan intentos quedan localizables para investigar y recuperar.
- Estado visible
- La aplicación puede distinguir pendiente, en proceso, terminado, fallido o cancelado.
- Prioridades
- Mensajería, pagos o webhooks críticos no compiten necesariamente con reportes o tareas diferibles.
Cerrar una ventana o reiniciar una API no debería hacer desaparecer un trabajo importante.
Separar responsabilidades
Un ecosistema de productos puede compartir plataforma sin compartir el mismo tipo de carga.
Web interactiva
Respuestas rápidas, caché, sesiones, permisos y experiencia de usuario.
Tiempo real y webhooks
Eventos, mensajería, recepción confiable y procesamiento sin bloquear.
Jobs de IA y servicios externos
Tiempos variables, cuotas, costos, reintentos y seguimiento de estado.
Procesamiento multimedia
CPU, memoria, almacenamiento temporal y concurrencia controlada.
Separar estos perfiles permite escalar la parte que realmente lo necesita, aislar fallas y evitar que una tarea pesada degrade una función crítica.
Interoperabilidad
La arquitectura debe asumir que la empresa ya tiene sistemas, datos y proveedores.
Diseñamos integraciones como contratos explícitos: qué entra, qué sale, quién autoriza, qué ocurre si el proveedor no responde y cómo se evita procesar dos veces el mismo evento.
- APIs
- Lectura y escritura de información mediante interfaces definidas.
- Webhooks
- Eventos entrantes que deben validarse, firmarse cuando corresponda y procesarse de forma idempotente.
- Sincronización
- Conciliación de estados entre sistemas sin asumir que todos actualizan al mismo tiempo.
- Fuentes de verdad
- Definición de qué sistema manda para cada dato o decisión cuando existen discrepancias.
- Fallback y recuperación
- Tratamiento de indisponibilidad, timeouts, reintentos y trabajo pendiente.
IA sin lock-in conceptual
El sistema debe sobrevivir a que cambie el modelo, el precio o el proveedor.
No diseñamos una operación alrededor del nombre de un modelo. Encapsulamos el uso de inteligencia artificial dentro de funciones concretas: interpretar, extraer, clasificar, generar, buscar o asistir.
El proveedor puede cambiar por costo, latencia, privacidad, calidad o disponibilidad. Las reglas de negocio, estados, permisos y evidencia no deberían desaparecer con ese cambio.
La IA es una capacidad del sistema. No sustituye la arquitectura del sistema.
Datos
Compartir contexto sólo tiene valor si podemos explicar de dónde vino y quién puede usarlo.
En sistemas que conectan productos o fuentes, no basta con mover información. Hay que conservar origen, tenant, permisos, versión, propósito y estado suficiente para decidir si el dato puede utilizarse en la siguiente acción.
- Origen
- Qué sistema o usuario produjo el dato.
- Contexto
- A qué organización, proceso, caso o entidad pertenece.
- Permiso
- Quién puede consultarlo o utilizarlo.
- Versión
- Qué cambió y cuál es el estado vigente cuando el proceso lo requiere.
- Auditoría
- Qué acción ocurrió, cuándo y con qué resultado.
- Retención
- Qué debe conservarse, archivarse o eliminarse según la naturaleza del dato y el acuerdo aplicable.
Operación
No basta con saber que “algo no funcionó”.
Errores, logs, métricas, trazas, colas y costos necesitan visibilidad suficiente para distinguir si una falla ocurrió en interfaz, API, base de datos, worker, integración o proveedor externo.
- Errores
- Captura de excepciones con contexto técnico suficiente para reproducir.
- Logs estructurados
- Eventos consultables, no sólo texto disperso en consola.
- Métricas
- Latencia, errores, saturación, colas y recursos observables.
- Trazas
- Seguimiento entre servicios cuando una operación cruza varios componentes.
- Costos variables
- Consumo de IA, media u otros proveedores registrado cuando es relevante para operar.
- Alertas
- Umbrales que convierten una anomalía en una acción para el equipo.
La observabilidad convierte una falla en algo localizable antes de convertirla en una explicación improvisada.
Reducir superficie de falla
Seguridad no es una insignia. Es una serie de decisiones verificables.
Diseñamos la seguridad desde identidad, aislamiento, secretos, red, almacenamiento, integraciones y recuperación. El nivel exacto depende del alcance y riesgo de cada sistema; no presentamos una arquitectura genérica como certificación o garantía de cumplimiento.
- Acceso mínimo
- Servicios internos y administrativos no necesitan estar expuestos públicamente por defecto.
- Secretos separados
- Credenciales por servicio y ambiente, con rotación y sin incrustarlas en el código.
- Protección de borde
- TLS, controles de abuso, rate limits y validaciones antes de llegar a los servicios internos.
- Backups y restauración
- Un respaldo sólo cuenta si existe una ruta documentada para restaurarlo y probarlo.
- Webhooks verificados
- Eventos externos deben validar origen, firma o mecanismo equivalente cuando el proveedor lo permite.
- Rollback
- Una versión desplegada debe poder retirarse o revertirse cuando introduce una falla crítica.
Aclaración
Las medidas aplicables se documentan por proyecto; esta página explica principios de ingeniería, no una certificación de seguridad.
Prueba
Escalar significa conocer dónde se rompe el sistema antes de prometer que no se romperá.
Las decisiones de capacidad se validan con pruebas: carga concurrente, saturación de colas, fallas de proveedores, caída de workers, restauración de datos y comportamiento bajo límites externos. Preferimos medir antes que convertir una estimación en promesa comercial.
La capacidad se prueba. La recuperación se ensaya. El rollback se diseña antes de necesitarlo.
La arquitectura debe traducirse en operación
Menos dependencia de improvisación técnica; más claridad para evolucionar el sistema.
| Decisión técnica | Consecuencia operativa buscada |
|---|---|
| Core reutilizable | No pagar una y otra vez por resolver capacidades comunes. |
| Lógica de producto separada | Cambiar una vertical sin convertir todo el ecosistema en una sola aplicación rígida. |
| IA + reglas | Mantener flexibilidad en lenguaje sin entregar reglas críticas a una salida probabilística. |
| Jobs y workers | Procesar tareas largas sin congelar la experiencia ni perder trabajo ante fallas temporales. |
| Multi-tenancy y permisos | Operar varias organizaciones con fronteras explícitas de acceso y contexto. |
| Observabilidad | Localizar fallas y cuellos de botella con evidencia. |
| Backups y recuperación | Reducir el costo de que algo salga mal y volver a un estado operable. |
| Integraciones explícitas | Conectar herramientas existentes sin depender de capturas manuales invisibles. |
Evidencia
La arquitectura cambia porque el problema cambia.
Zyllon
Arquitectura conversacional vertical: lenguaje natural combinado con reglas, scoring, multi-tenancy y flujo controlado.
Ver proyecto →WABEE
Mensajería y webhooks en tiempo real, seguimiento, campañas, conocimiento e inteligencia conversacional.
Conocer WABEE →SocialQuant
Publicación, scoring, inbox, análisis y procesos asíncronos sobre varias plataformas sociales.
Conocer el ecosistema →Dafne
Procesamiento de imagen, voz y video con carga multimedia separada de las peticiones web ordinarias.
Conocer el ecosistema →Método
No buscamos la arquitectura más compleja. Buscamos la complejidad mínima que sostiene el problema real.
01
Riesgo
Qué ocurre si el sistema falla, duplica, pierde, retrasa o expone información.
02
Carga
Qué tipo de trabajo existe: interactivo, tiempo real, asíncrono, analítico o multimedia.
03
Datos
Dónde vive la fuente de verdad y qué nivel de aislamiento, historial y recuperación necesita.
04
Dependencias
Qué servicios externos pueden fallar, limitar o cambiar condiciones.
05
Operación
Quién monitorea, responde incidentes, despliega y restaura.
06
Costo
Qué parte es fija, variable y sensible a volumen.
07
Evolución
Qué decisiones deben poder cambiar sin reconstruir todo el sistema.
Una arquitectura útil no es la que tiene más piezas. Es la que hace explícitas las responsabilidades necesarias para que el sistema pueda operar y cambiar.
Construir con criterio
Si tu operación ya superó hojas, herramientas aisladas o automatizaciones difíciles de mantener, podemos revisar qué arquitectura necesita realmente.
No necesitas llegar con un stack elegido. Cuéntanos qué sistema existe, qué debe conectarse, qué datos son críticos, qué parte necesita inteligencia artificial y qué no puede quedar sin control.