FidelyHub.

Una plataforma de tesis que conecta varios programas de fidelización detrás de una sola API y una sola wallet. Los administradores configuran cada proveedor desde un backoffice y los usuarios consultan saldos, recompensas y actividad sin cambiar de app.

Tech-stack que usé aquí

Origen y propósito

  • El problema es la fragmentación: Cada programa llega con su propia autenticación, payload y paginación, así que cada proveedor nuevo significaba código y despliegue nuevos.

  • Una tesis con forma de producto: El objetivo era el recorrido completo: configuración administrativa, identidad, gateway, servicios y wallet móvil, no una demo CRUD.

  • El activo reutilizable es la capa: Una wallet de una sola marca repetiría el mismo trabajo por cada programa; la capa de abstracción es lo que hace reutilizable la tesis.

Decisiones

  • Un contrato, siete operaciones: Validar usuario, saldo, recompensas, débito, reverso, actividad y viabilidad de producto comparten el mismo contrato en todos los proveedores.

  • Configuración antes que código: Programas, credenciales, endpoints, placeholders, mapeos por rutas JSON y paginación OFFSET o CURSOR son datos, no despliegues.

  • Seguridad desde el diseño: Las credenciales se cifran con AES-256-GCM y scrypt, nunca se devuelven por la API, y Keycloak y KrakenD aplican identidad y roles en el borde.

  • Los fallos quedan aislados: Saldos y actividad se reparten con Promise.allSettled, y el checkout usa un errgroup de Go limitado a cinco, para que un proveedor no tumbe la wallet.

  • Webhooks con idempotencia: Firmas HMAC-SHA256, una ventana de repetición de cinco minutos y un eventId único mantienen fuera los eventos duplicados.

Un contrato, todos los proveedores

Arquitectura de configuración y ejecución de FidelyHubLos clientes se autentican con Keycloak y entran por el gateway KrakenD; el servicio de integración guarda la configuración de cada proveedor, el servicio de wallet ejecuta el mismo contrato con el cliente compartido y el servicio Transactions, escrito en Go, procesa el checkout por lotes.Plataforma FidelyHubBackoffice + appadmins configuranusuarios consultanKeycloak + KrakenDOIDC · RS256roles · routingIntegration serviceprogramas · endpointswebhooks · pruebas en vivoPostgres · Supabaseconfig · vínculosauditoríaWallet servicesaldos · recompensasactividad · checkoutTransactions serviceGo · débito por loteregistro de auditoríaAPIs externasfidelizaciónauth · payloadpaginaciónaerolíneabancohotelsupermercadoConfigura una vez,ejecuta por un solo gateway,deja los proveedores fuera.

Resultados

  • Ocho piezas, un producto: Backoffice Next.js, app Expo, dos servicios NestJS, un servicio Go, cliente compartido, KrakenD y Keycloak.

  • Un proveedor sin despliegue: El backoffice crea programas, conexiones, endpoints y webhooks, y ejecuta pruebas en vivo contra la API antes de activarlos.

  • Una wallet entre programas: Saldos consolidados, actividad de todos los programas y checkout de carrito con resultados por proveedor, incluidos los fallos parciales.

  • Canjes auditables: Cada intento del checkout guarda request, response, estado, ID externo de transacción y código de autorización.

  • Calidad donde importa: Los tests cubren validadores, estrategias de endpoints, mapeo de webhooks y el executor de Go; la CI filtra por rutas y los deploys usan autenticación sin claves.