Muchos errores descubiertos justo antes del despliegue siguen patrones conocidos: el frontend calcula un descuento del 10% y el backend del 15%, o la documentación marca un campo como obligatorio que ha desaparecido de la API real. Ambos códigos funcionan. El problema es que la misma información existía en dos sitios y solo uno cambió.
El principio que evita estructuralmente estos incidentes es Single Source of Truth, o SSOT. El nombre suena grandilocuente, pero cabe en una frase: cada fragmento de información debe tener exactamente una fuente original autorizada.
Resumen clave.
- SSOT significa que existe una sola fuente original de la información; no que deba existir un único repositorio
- La información duplicada siempre diverge. El problema no es cuándo diverge, sino cuándo nadie sabe cuál versión es correcta
- Si necesitas una copia, créala como «derivada». En lugar de escribirla dos veces, genérala automáticamente desde el original
- La caché y las réplicas no infringen SSOT. Basta con dejar clara la fuente original y la dirección de actualización
Por qué la duplicación siempre provoca divergencias
En cuanto colocas la información en dos sitios, la responsabilidad de mantenerlos iguales pasa a las personas, porque ni las herramientas ni el compilador conocen ese acuerdo. Cada cambio exige recordar «¿dónde estaba también este valor?». Si se olvida una sola vez, ambos valores toman caminos distintos.
Lo peor llega después de la divergencia. Si una constante tiene valores distintos en dos partes del código, el código por sí solo no revela cuál es correcta. Hay que revisar el historial de git, localizar a quien la mantenía y consultar documentos de planificación: empieza la arqueología. El verdadero coste de romper SSOT no es corregir el error, sino decidir «cuál es la verdad».
Veamos algunos casos habituales.
- Duplicación de constantes: el límite de subida de 10MB está escrito directamente en la validación del frontend, la del backend y el mensaje de error
- Duplicación de la lógica de validación: cliente y servidor validan el formato del correo con expresiones regulares diferentes
- Documentación y código: la especificación de la API y la implementación están separadas. Meses después, la documentación se convierte en ficción
- Base de datos y caché: se olvida invalidar la caché tras actualizar el original y se siguen sirviendo datos antiguos
- Diseño y código: los valores de color del diseño y los codificados en la aplicación difieren ligeramente
La forma cambia, pero la estructura es la misma: hay dos fuentes originales y la sincronización depende de las personas.
El principio no es «prohibir copias», sino «derivar»
SSOT suele malinterpretarse como «guardar la información en un solo lugar». Entonces la caché, las réplicas de lectura y los artefactos de compilación parecen infracciones. El principio real es otro: puede existir en varios lugares, pero solo hay una fuente original y todo lo demás debe derivarse de ella.
La generación de código es una forma representativa de crear derivados.
- Generar tipos desde el esquema: al generar tipos de cliente y stubs de servidor desde la especificación OpenAPI, esta se convierte en la fuente original y desaparece la posibilidad de divergencia
- Tokens de diseño: define colores y tipografía en un único archivo de tokens y genera por separado el código para iOS, Android y web
- Módulo de constantes compartidas: si frontend y backend importan las constantes del mismo paquete, se elimina de raíz la copia codificada
- Extraer documentación del código: al generar la documentación de la API desde comentarios y tipos, siempre sigue al código
El punto común es convertir el lugar donde una persona escribe dos veces en uno donde una máquina genera una vez. La responsabilidad de sincronización pasa de la memoria humana al pipeline de compilación, y CI detecta primero las divergencias.
La caché y las réplicas encajan igual. Si declaras dónde está el original, haces que las actualizaciones fluyan en una sola dirección —original→copia— y defines cuánto puede quedar obsoleta la copia (TTL y estrategia de invalidación), SSOT se mantiene. La infracción no ocurre cuando existe una copia, sino cuando empiezas a modificarla directamente.
El mismo principio se aplica a las organizaciones
SSOT no trata solo del código. Decidir qué servicio es dueño de un dato en una arquitectura de microservicios y designar la versión oficial entre documentos de políticas repartidos por la wiki interna, Notion y Slack son el mismo problema.
Los documentos divergen más fácilmente que el código, sobre todo porque no tienen compilador ni pruebas. Por eso, en el SSOT organizativo el consenso precede a las herramientas: «la fuente del proceso de incorporación es esta página de la wiki; en otros sitios solo habrá un enlace». Sustituir copias por enlaces es la derivación del mundo documental.
Lista de comprobación práctica
Estos son los criterios que puedes aplicar desde mañana.
- Escribir el mismo valor por segunda vez es una señal: si copias constantes, reglas de validación o configuración, comprueba primero si puedes moverlas a un módulo compartido o generarlas
- Declara la fuente original: cachés, réplicas y resúmenes no son el problema. Comprueba que código y documentación indiquen «el original está aquí» y que la actualización sea unidireccional
- Haz que las herramientas detecten las divergencias: incorpora validación de esquemas, pruebas de contrato y comprobaciones de diff del código generado en CI para detectar fallos antes de fusionar
- Cuidado con el perfeccionismo: crear abstracciones excesivas para eliminar toda duplicación también tiene un coste. Prioriza la información que cambia a menudo o cuya divergencia resulta cara
Tiene la misma raíz que el principio DRY (Don’t Repeat Yourself) del refactorizado. DRY apunta a duplicar lógica de código; SSOT amplía la idea a datos y conocimiento. Cuando preguntes «este valor también está allí, ¿debemos cambiarlo?», habrás encontrado un lugar para establecer SSOT.