Una base común, recorridos independientes
No hay que implementar toda la plataforma para obtener valor de una parte. Cada recorrido es completo por sí mismo, desde la entrada de datos hasta el resultado.
El sistema completo
Los datos entran por cuatro caminos con el mismo contrato, se apoyan en una base compartida y alimentan recorridos que se venden por separado.
Decisiones que evitan rehacer el núcleo
La mayoría de estas decisiones no se notan cuando todo va bien. Se notan el día que hay que crecer, migrar o auditar.
Núcleo modular, no microservicios por defecto
Los módulos se separan por límites de dominio y pueden desplegarse aparte cuando la carga lo justifique. Convertir cada módulo en un servicio desde el día uno agrega operación sin agregar valor.
Seguir en el diagramaLa API no expone la topología
Cómo estén repartidos los procesos por dentro es asunto nuestro. El contrato público no cambia porque decidamos separar o unir un módulo.
Ver la APINinguna tabla es un contrato
Las aplicaciones consumen contratos versionados, no el esquema de base de datos. Eso permite migrar el almacenamiento sin romper a los consumidores.
Ver la APIMotores de ruteo intercambiables
La API de rutas es propia y el motor que la resuelve es reemplazable. La elección se hace por medición, no por preferencia.
Ver productividadMigraciones que no rompen a quien está offline
Se agregan campos compatibles, se despliega, se migran los datos y solo después se retira lo antiguo. Un teléfono sin señal debe poder sincronizar durante la ventana acordada.
Ver DromiviaSeguridad en la base, no encima
Identidad, permisos, segmentación, límites de datos y recuperación se comprueban por separado. Que falle una barrera no debe entregar el sistema completo.
Ver seguridadPreparados para crecer, sin pagar por adelantado
La plataforma se diseña con contratos que admiten crecer, y la infraestructura se adopta cuando la carga medida la justifica. Instalar una pila de herramientas por prestigio agrega costo de operación y superficie de fallo antes de que exista el problema que resolverían.
Eso significa dos cosas concretas. La primera: los contratos y las migraciones se preparan desde el diseño, para que adoptar una cola de eventos, un almacén analítico o un orquestador más adelante sea trabajo acotado y no una reescritura. La segunda: no prometemos que esa migración sea gratis, porque no lo es.
Un solo servidor sigue siendo un único dominio de fallo, por bien configurado que esté. Cuando la disponibilidad ofrecida lo exija, la separación se hace de verdad y se documenta; réplicas del mismo proceso en la misma máquina no demuestran disponibilidad entre dominios de fallo.
Preguntas frecuentes
¿Quieres revisarlo con tu equipo técnico?
Podemos entrar en el detalle de contratos, migraciones y modelo de datos con quien vaya a integrarnos.
