Plataforma cloud multi-tenant / Producción
SpeedFlowLink
Plataforma cloud para la gestión de estaciones de dispensación de combustible — frontend Blazor, varias APIs con responsabilidades separadas y un modelo de datos multi-tenant compartido.
El problema
Una estación de dispensación combina dispositivos físicos, operadores en piso, autoservicio, facturación y sistemas de terceros. Cada uno habla un protocolo distinto y tiene un ciclo de vida propio: los dispositivos se reemplazan, la operación no puede detenerse y los datos de un cliente jamás pueden filtrarse a otro. Un único servicio monolítico habría acoplado el ritmo de despliegue del hardware al de la interfaz web.
Restricciones
- Aislamiento estricto por cliente sobre una base de datos compartida
- Los dispositivos en campo no se pueden actualizar al mismo ritmo que el cloud
- Operación continua — el esquema evoluciona sin ventanas de mantenimiento largas
- Superficies con requisitos opuestos — la web tolera latencia, el hardware no
Decisiones
Resultado
- Frontend Blazor Server que consume las APIs mediante servicios HTTP inyectados, con la lógica en ViewModels y las vistas delgadas
- Modelo de datos con convención de prefijos por área — parámetros, administración, generales, clientes y seguridad — que hace legible el esquema sin abrir la documentación
- Estado de dispositivos en tiempo real hacia la interfaz mediante un hub de mensajería
- Canal de integraciones con sistemas de terceros aislado del núcleo de negocio
Cómo está partido el sistema
La solución no es un servicio grande sino un conjunto de servicios agrupados por a quién le hablan, sobre una base de datos común:
- API principal de negocio — sirve a la interfaz web y concentra la lógica de dominio, las entidades y la evolución del esquema.
- Device API — canal hacia los dispositivos de hardware, con control directo sobre ellos.
- SoftAPI — servicio autocontenido para la comunicación con los dispositivos por software. Comparte la base de datos pero se despliega por su cuenta.
- API de integraciones — punto de entrada de sistemas de terceros, aislada del núcleo.
- Hub de tiempo real — empuja el estado de los dispositivos hacia la interfaz sin que el navegador tenga que preguntar.
- Autoservicio — superficie para operación desatendida.
Esa partición es la decisión estructural del producto: permite que el canal de dispositivos —el que no puede fallar— evolucione a un ritmo distinto del de la interfaz web.
Multi-tenant como invariante, no como convención
Todos los clientes comparten la base de datos. El aislamiento se resuelve en el acceso a datos: el repositorio recibe el contexto del usuario autenticado y aplica el filtro de propietario de forma uniforme. Ninguna consulta decide por su cuenta si filtrar.
Es la clase de regla que, si se deja a criterio de cada desarrollador, funciona hasta el día en que alguien escribe una consulta nueva con prisa.
Mi participación
Trabajé sobre integraciones, backend, frontend y modelo de datos. Eso incluye escribir endpoints y servicios de dominio, construir pantallas Blazor con su ViewModel, diseñar y evolucionar tablas, y —lo que más aprendí— mantener coherentes las tres cosas cuando un cambio de negocio las atraviesa.
El recorrido completo, no solo la implementación: levantamiento del requerimiento con quien lo pide, diseño de la solución, desarrollo, pruebas, integración continua y acompañamiento del despliegue.
Por qué está aquí
Es el sistema donde más tiempo llevo y donde las decisiones tienen consecuencias medibles a años vista. Muestra trabajo sostenido sobre un producto real: no una arquitectura dibujada en una pizarra, sino una que sobrevivió cinco años de requerimientos cambiantes.
El código es propiedad de Speed Solutions. Este caso describe arquitectura y decisiones, sin incluir código fuente, datos de clientes ni cifras de negocio.