Un dato, dos sistemas, dos verdades
Es común que dos sistemas muestren la misma cifra y que, con el tiempo, empiecen a mostrar cifras distintas. La causa casi nunca es un bug: es una decisión de diseño que no se tomó a tiempo.
Lectura: 5 minutos
Un negocio que vende software tiene dos cosas que mirar todos los días: cuánto cuesta operar (servidores, servicios, consumo de los modelos de lenguaje que usan los productos) y cuánto consume cada cliente, que es lo que se factura. Ese número nace en un lugar: el sistema que cobra y administra. Pero también lo quiere ver el sistema de gestión interno del negocio. Y ahí aparece la tentación obvia: que el segundo se guarde su propia copia.
El síntoma
El síntoma clásico es una discusión que no debería existir: dos pantallas muestran el mismo indicador con valores distintos. Al principio la diferencia es mínima y se atribuye a un retraso de sincronización. Después crece, y la conversación deja de ser cuánto se gastó para convertirse en por qué tu pantalla dice otra cosa que la mía, que es una discusión mucho más cara.
Hay un segundo síntoma, más silencioso: cuando nadie sabe cuál de los dos números es el correcto, las decisiones se toman con el que esté a mano. Eso es peor que no tener el dato.
La causa real
Copiar un número parece inofensivo. El problema es que un dato guardado en dos lugares deja de ser un dato y pasa a ser dos. Al día siguiente uno de los dos se actualiza, el otro no, y ahora existen dos cifras del mismo gasto. La causa no es de programación: es de diseño, y se manifiesta en el peor momento.
La decisión
La decisión: una sola fuente de verdad. El número vive donde nace y nadie lo re-almacena. El sistema que lo produce lo expone como un servicio de consulta; el resto lo lee desde ahí. Si mañana aparece un tercer sistema, también lee del productor.
La regla se puede escribir en una línea: el que produce el dato lo publica; el resto lo consulta. Ningún sistema copia a su propia tabla lo que puede preguntar. El costo de esa decisión es una dependencia explícita entre sistemas: el consumidor ya no puede operar si el productor no responde. A cambio, se elimina la deriva silenciosa entre dos copias.
Los detalles que hacen la diferencia
Cuando el consumidor del dato es otra máquina y no una persona mirando una pantalla, aparecen dos exigencias que en un panel normal no importan:
| Exigencia | Por qué |
|---|---|
| Devolver siempre la misma forma de respuesta | Si no hay datos, devuelve cero y listas vacías, nunca un error. Un servicio que falla por 'no hay nada que mostrar' obliga al otro sistema a defenderse, y ahí el contrato se vuelve inútil. |
| No mezclar los dos bolsillos | El costo de operación del negocio y el insumo facturable de cada cliente son dos cosas distintas. Si se suman, el costo real por cliente queda falseado y se toman decisiones de precio con un número inventado. |
El acceso sin abrir un agujero
El servicio de consulta no lo puede pedir cualquiera: exige una credencial propia, y esa credencial identifica al sistema que pregunta, no a un usuario. El usuario final del negocio no la tiene ni la necesita. Una credencial de cliente no sirve para leer los números globales del negocio, y eso conviene probarlo, no asumirlo.
La lección
Antes de conectar dos sistemas, decide dónde vive el dato. Si la respuesta es 'en los dos', el problema no es de programación: es de diseño, y se va a notar en el peor momento.
Un negocio que factura todos los meses necesita que el número del gasto sea el mismo para todos los que lo miran: el cliente, el que cobra y el que decide. Cuando el dato es uno solo, la conversación se puede tener. Cuando son dos, primero hay que pelear cuál es.
Bitácora de Thot-ecosystem · Arquitectura.