Identidad y sesiones
Registro con verificación, login, refresh, MFA, OAuth de Google y sesiones por dispositivo. Límites de intentos y revocación en vivo.
Laboratorio
La plataforma donde pruebo arquitectura de verdad
El hub de servicios distribuidos: un núcleo que resuelve lo común —identidad, suscripciones, cobros y soporte— y tools independientes que se enchufan encima.
ARQUITECTURA
Autenticación central, servicios simples
El núcleo concentra la autenticación: firma las credenciales y cada servicio las verifica por su cuenta, con el mismo estándar que usan Google y Microsoft para conectar sus servicios. El usuario entra una sola vez, la seguridad se endurece en un solo lugar y una API nueva arranca sin rearmar el login.
MÓDULOS DEL NÚCLEO
Lo que el núcleo resuelve
Seis módulos que el núcleo ya trae hechos: identidad, dinero, tareas de fondo, notificaciones, panel y seguridad.
Wallet y cobros
Libro mayor inmutable por usuario: la tool mueve dinero por la saga reserve/settle/credit, sin escribir nunca la base.
Tareas de fondo
Colas asíncronas que escalan en horizontal por réplicas, con reintentos, DLQ y webhooks firmados.
Notificaciones
Email, SMS, WhatsApp y push web, con newsletter, campañas y avisos in-app: plantillas por canal e idioma para editar la comunicación.
Panel del usuario
Perfil, billetera, compras, pagos, sesiones y avisos en una misma pantalla dentro del núcleo: las tools reutilizan sus componentes en vez de armar cada una el suyo.
Sentinel
Sistema de seguridad central y aislado que agrega telemetría, detecta ataques distribuidos y propaga la denylist, con análisis de comportamiento y evaluación de riesgo.
PIEZAS
Qué implica cada decisión
Cuatro decisiones sostienen el sistema, y cada una deja una consecuencia concreta cuando hay más de un producto en juego.
Lo común se arregla una vez
Un cambio en el núcleo —el login, una regla de seguridad, un cobro— se despliega una vez y sirve para todos los productos.
Sumar una tool no toca a las otras
Una tool nueva es una carpeta de más —app, cliente de API y API propia—: se despliega sola, sin tocar el núcleo ni las que ya están andando.
Los datos no se mezclan
Cada servicio tiene su base y su caché propias: un cambio de esquema o un borrado se quedan de su lado y no alcanzan a los demás.
Una receta para todas
Las tres capas —app, cliente de API y API serverless— son las mismas en todas: armar la próxima tool es copiar la estructura, no decidirla otra vez.
EQUIPOS CON AGENDA
SaaS de reservas online
El SaaS de reservas de la plataforma: cada equipo publica su sitio con su propio slug, sus servicios y su calendario, y cualquiera reserva sin crear cuenta. El calendario del profesional se sincroniza en los dos sentidos —un compromiso que ya tenía afuera bloquea el horario acá— y su agenda es una sola en todos los equipos donde esté: dos turnos no se pisan, ni entre equipos.
El recorrido de un pedido
- El sitio del equipoCada equipo publica su landing con su propio slug y la arma por secciones; el plan del equipo decide cuántos miembros entran y qué variantes del sitio se habilitan.
- Servicio, día y horaEl visitante elige servicio, profesional y día; el calendario habilita sólo los horarios libres y el bloqueo se sostiene mientras termina.
- La reservaLa API escribe el turno contra un índice único por profesional y horario: dos pedidos a la misma hora no se pisan, ni con una carrera, y el mismo profesional no queda en dos lugares aunque esté en varios equipos.
- El calendario compartidoEl turno entra en la Calendar API de la plataforma: cada tool escribe su capa y el calendario total del usuario se compone al leer, con lo que cada miembro puede ver. Un profesional ocupado en otra tool aparece ocupado acá.
- El ida y vuelta con GoogleLa Calendar API es la única pieza que habla con Google Calendar y sincroniza en los dos sentidos: un compromiso que el profesional ya tenía bloquea el horario en el sitio, y el turno confirmado aparece en su calendario.
- El recordatorioEl núcleo agenda la tarea de 24 horas antes y vuelve a la tool con la llamada firmada: el aviso sale sin que la tool tenga un proceso propio esperando.
- El staff confirmaQuien atiende entra con su cuenta del núcleo y su rol del equipo, confirma el turno y lo ve en el calendario de la agenda.
- Fuera del requestLa reserva ya está confirmada: la telemetría y el evento de seguridad salen por atrás y el sentinel central los cruza con el resto de la plataforma.
Su API serverless, su base y su caché propias: del núcleo toma la identidad, la tarea del recordatorio y el sentinel, y el calendario no vive acá —cada mutación se publica en la Calendar API de la plataforma, que es la que sincroniza con Google—.
EMPRESAS DE MANTENIMIENTO
Sistema de mantenimiento de ascensores
El sistema de las empresas que mantienen ascensores: consorcios, edificios y equipos con ficha técnica, visitas que el técnico cierra desde el celular —el informe reemplaza al grupo de WhatsApp— y mantenimientos que vuelven mes a mes sin que nadie los cargue de nuevo. Los roles se arman permiso por permiso y el plan decide cuántos edificios, ascensores, miembros y recurrencias entran.
El recorrido de un pedido
- El técnico, en el edificioAbre la app desde el celular con su cuenta del núcleo: la API verifica el token contra el JWKS, sin preguntarle al núcleo en cada pedido.
- La ficha del equipoConsorcio, edificio y ascensor, con su ficha técnica y su historial: la visita arranca sabiendo qué se hizo la última vez.
- La visita y el informeEl técnico registra lo que hizo y adjunta el informe desde el lugar; queda en el historial del equipo y en el mes que le toca.
- El mes que vuelveEl mantenimiento se repite mes a mes: el núcleo despierta la tarea y vuelve a la tool con la firma, así que nadie tiene que acordarse.
- El consorcio miraLa administración entra con su propio rol y ve los edificios, los equipos y lo que vence: los permisos son de la tool, no del núcleo, y el plan decide cuántos edificios, ascensores, miembros y recurrencias entran.
- Fuera del requestLo que no puede costarle un segundo al técnico sale por atrás: los rechazos y los eventos de seguridad van al sentinel central, que los cruza con el resto de la plataforma.
Corre con su base y su caché propias: del núcleo toma la identidad, el reloj que despierta las recurrencias del mes y el sentinel.
EQUIPOS DE DATOS
Tableros sobre tu propia hoja
El servicio de análisis: el usuario conecta su hoja de Google Sheets y arma tableros y reportes arriba de ella —los datos no se migran ni se espejan: el cálculo es al vuelo y sólo se guarda la configuración—. El token de esa conexión se cifra con AES-256-GCM y no vuelve a salir, y el proveedor de hojas vive detrás de un puerto, así que sumar Excel no toca el contrato.
El recorrido de un pedido
- La sesiónEl usuario entra con su cuenta del núcleo y la API verifica el token en el acto contra el JWKS: ninguna llamada de identidad por pedido.
- La hoja conectadaGoogle Sheets o Excel entra por OAuth; la hoja no se migra ni se espeja, se lee donde está.
- El token cifradoEl token de esa conexión queda cifrado (AES-256-GCM) y no vuelve a salir: sin la clave de cifrado, la API falla cerrada.
- El tableroGráficos y tablas sobre la hoja; lo que se guarda es la configuración del tablero, no una copia de los datos.
- La cuenta al vueloCuando el tablero se abre, la API vuelve a pedir la hoja y agrega en el momento: el número que se ve es el de la hoja de hoy.
- Fuera del requestLa telemetría y los eventos de seguridad salen por atrás para que los cruce el sentinel central; el análisis no espera por eso.
De los seis módulos del núcleo usa dos: la identidad para la sesión y el sentinel para los eventos. Todo lo demás —la hoja, el token cifrado y los tableros— es suyo.
¿Querés verlo en acción?
El código todavía no es público, pero puedo recorrerlo con vos: pedime una demo y te muestro el núcleo, las tools, la saga de wallet y el sentinel por dentro.
Pedir una demo →