Un Append-only Ledger es un tipo de estructura de datos que impone una política estricta de inmutabilidad: una vez que un registro ha sido escrito, no puede ser alterado ni borrado. Las operaciones permitidas se limitan a añadir nuevos registros al final de la secuencia. Cada nueva entrada se vincula criptográficamente o secuencialmente a la anterior, formando una cadena o historial lineal. Esta característica fundamental asegura la integridad y la trazabilidad de los datos a lo largo del tiempo, ya que cualquier intento de manipulación de un registro anterior invalidaría la secuencia subsiguiente.
Este patrón de diseño es fundamental en sistemas que requieren alta integridad y auditabilidad. Ejemplos prominentes incluyen bases de datos de transacciones financieras como las utilizadas por bancos y bolsas de valores, donde cada movimiento debe ser registrado de forma inmutable. Las tecnologías de DLT (Distributed Ledger Technology) como Blockchain son el ejemplo más conocido, donde cada bloque es un 'append' a la cadena anterior. Sistemas de logs distribuidos como Apache Kafka y Amazon Kinesis Streams también operan bajo este principio, donde los eventos son publicados y persisten en un log inmutable, permitiendo múltiples consumidores procesar el mismo flujo de datos de manera consistente. Bases de datos inmutables como Datomic o sistemas de auditoría de seguridad también lo emplean para garantizar la no repudiación de los eventos.
Para un Arquitecto de Sistemas, la elección de un Append-only Ledger es estratégica cuando la integridad de los datos, la auditabilidad y la trazabilidad son requisitos críticos. Ofrece una fuerte garantía de consistencia histórica y simplifica la recuperación ante desastres al tener un historial completo e inmutable. Sin embargo, implica trade-offs: el almacenamiento puede crecer indefinidamente, ya que los datos nunca se eliminan (aunque pueden ser marcados como lógicamente 'borrados' con una nueva entrada). La gestión del tamaño y el rendimiento de las consultas sobre grandes volúmenes de datos históricos requiere estrategias de indexación y particionamiento cuidadosas. Además, la inmutabilidad puede complicar la implementación de la 'derecho al olvido' (right to be forgotten) de GDPR, requiriendo soluciones de cifrado o tokenización para datos sensibles.