Identidad anclada en SaaS multi-tenant: cuando una persona viste muchos roles

Estudio de caso · ingeniería de plataformas. Metodología Meta Dados (Genba · Kanso · Omotenashi).

Resumen. En SaaS multi-tenant del dominio de servicios, el mismo ser humano aparece como cliente, empleado y dueño — a veces en varios establecimientos. Modelamos este problema como un grafo de identidad anclada: una entidad global (la persona, anclada por el CPF) hacia la cual convergen vínculos desnormalizados por tenant. Un experimento controlado, ejecutado en la base de datos de producción bajo transacción con ROLLBACK, muestra que la identidad se unifica correctamente por el CPF, pero que el dato desnormalizado diverge silenciosamente entre tablas y que una clase de puertas que crea login "inline" con CPF nulo parte a un humano en dos identidades. Describimos dos intervenciones verificadas y derivamos principios reutilizables.

Las plataformas de agendamiento tratan tres entidades como ciudadanas de primera clase — cliente, empleado y establecimiento — cada una con su clave natural: el cliente se reconoce por el teléfono; el empleado exige CPF; el establecimiento se identifica por CNPJ + correo electrónico (o CPF, en el caso del autónomo). El problema surge porque estas tres no son disjuntas: un cliente puede ser contratado y convertirse en empleado; un cliente puede abrir su propio negocio; un dueño puede agendar como cliente en otro salón. El sistema necesita que la información circule entre las tablas y se mantenga coherente, sin dato vital divergente en registros diferentes.

Tratamos la plataforma Marcaê como estudio de caso, pero el modelo y los hallazgos son generales: valen para cualquier SaaS donde un individuo asume roles heterogéneos a lo largo del tiempo y entre inquilinos.

La idea central es separar identidad de rol. La persona es una entidad global — sin tenant, anclada por una clave fuerte (el CPF normalizado). Cada vínculo (cliente, empleado, usuario) lleva una copia desnormalizada de los campos vitales y una clave foránea person_id que apunta a la persona. Un disparador de base de datos (vincular_pessoa_por_cpf) hace el find-or-create: al grabar un vínculo con CPF válido, asocia (o crea) la persona de aquel CPF y fija el person_id. Sin CPF válido, la identidad es local al tenant.

El modelo debe garantizar dos invariantes. El primero es la unificación de identidad (I1): dos vínculos con el mismo CPF válido apuntan a la misma persona. El segundo es la completitud de roles (I2): la persona conoce todos los roles (tenant + rol) derivados de sus vínculos.

Para medir la coherencia de los datos vitales (nombre, correo electrónico, teléfono), definimos una tasa de divergencia δ: la fracción de personas en las que algún campo vital tiene más de un valor no vacío entre el ancla y sus vínculos. δ = 0 es el objetivo — la persona es la fuente única de verdad.

Una clase de puertas crea la cuenta de login "inline" (junto con el cliente) usando un anclaje que ignora el CPF — en la práctica, crea una persona nueva, siempre. Si un humano pasa por una puerta que ancla y por una puerta que no ancla, pasa a estar representado por dos personas — violando I1. La tasa de partición σ crece proporcionalmente al uso de las puertas que no anclan. Es el defecto de mayor severidad, porque, una vez partida, la identidad solo se reconcilia mediante operación manual/SQL.

Adoptamos Genba — ir al piso de fábrica: en vez de razonar sobre el modelo pretendido, ejercitamos el modelo real. Dos técnicas: (1) lectura exhaustiva de las 15 puertas donde nace o se transforma un cliente/empleado/usuario/dueño, registrando lo que cada una escribe y si ancla en el CPF; (2) simulación transaccional — instanciamos trayectorias de identidad directamente en la base de datos de producción, dentro de BEGIN … ROLLBACK: el disparador de anclaje se activa de verdad, pero nada persiste.

Los resultados confirmaron el modelo y señalaron dónde falla:

• I1 vale donde hay anclaje — una persona recorriendo 5 roles en 2 tenants grabó el mismo person_id.
• El dato vital diverge — el ancla retiene solo lo que vio primero: el correo electrónico que el empleado recibió después nunca subió a la persona; los nombres divergieron entre las tablas.
• σ = 0,5 en el escenario controlado — 1 de 2 humanos fue partido en dos identidades por la puerta que crea login inline.

Deduplicación como relación de equivalencia. La regla antigua colapsaba dos registros solo por el teléfono; la nueva exige teléfono Y nombre normalizados. Así, dos humanos distintos que comparten un teléfono (la madre que agenda desde su propio celular para el hijo) dejan de fusionarse por error.

Fusión como fold campo a campo. Cuando dos registros son de hecho la misma persona, la fusión deja de ser "elige uno y descarta el otro" y pasa a ser resolución por campo: una tabla de diferencias presenta cada campo divergente lado a lado, y el operador elige el valor que queda en el superviviente. El orden importa — reconectar las referencias y archivar los eliminados antes de aplicar la elección — de lo contrario el índice único parcial colisiona. Una fusión que pierde datos es una regresión; la fusión campo a campo preserva lo mejor de cada registro.

El caso ilustra un trade-off recurrente: desnormalizar campos vitales en los vínculos hace que cada pantalla sea rápida y autónoma, a costa de la coherencia; mantener a la persona como fuente única de verdad elimina la divergencia, a costa de acoplamiento en la lectura. Principios reutilizables para cualquier plataforma multi-tenant con identidad compartida:

• Un ancla, una clave. Elige una entidad global y una clave fuerte (CPF/CNPJ) y haz que toda puerta ancle por ella. Una única puerta que ancla con nulo rompe la garantía.
• El anclaje es invariante de estado, no de rol. Modela los roles como estados; la transición cliente→empleado→dueño debe preservar el person_id. "Transformar" un rol es agregar un vínculo, nunca crear una nueva identidad.
• Decide la coherencia por campo. El correo electrónico y el teléfono piden fuente única; las observaciones locales pueden vivir en el vínculo. La métrica δ mide el costo de cada decisión.
• La deduplicación es una relación de equivalencia — elígela explícitamente. "Mismo teléfono" y "mismo teléfono y nombre" producen particiones diferentes.
• La reconciliación es fold, no descarte.

La identidad de Marcaê se unifica correctamente cuando hay CPF — el ancla funciona y es robusta ante transiciones de rol. La clase de puertas que partía la identidad fue cerrada mediante disparador en la base de datos (la reconciliación garantiza que la cuenta siga a la persona del CPF, la fusión dejó de generar login huérfano, y el ancla pasó a aprender los datos vitales que le faltaban). Resta solo la fuente única de verdad plena — decisión de diseño, no defecto. La ganancia no es solo técnica: es la garantía de que un cliente que se convierte en empleado, o un dueño que se convierte en cliente, sigue siendo la misma persona en todo el sistema.