Una Persistent Data Structure (PDS) es una estructura de datos inmutable que, tras cualquier operación de modificación, devuelve una nueva versión de la estructura sin alterar la versión original. Esto contrasta con las estructuras de datos 'efímeras' o 'mutables', donde las operaciones modifican el estado existente. La 'persistencia' en este contexto se refiere a la persistencia de versiones, no a la persistencia en almacenamiento no volátil. Las PDS pueden ser 'parcialmente persistentes' (solo la versión más reciente puede ser modificada, pero todas las versiones son accesibles) o 'completamente persistentes' (cualquier versión puede ser modificada, resultando en una nueva versión que coexiste con las anteriores). Su implementación a menudo utiliza técnicas como 'path copying' o 'structural sharing' para minimizar la duplicación de datos y optimizar el uso de memoria.
Las Persistent Data Structures son fundamentales en lenguajes de programación funcional como Clojure (donde sus colecciones como 'vectors', 'maps' y 'sets' son persistentemente inmutables por defecto), Scala y Haskell. También se utilizan en sistemas de control de versiones como Git, donde cada 'commit' representa una nueva versión del repositorio que comparte la historia de archivos inmutables. Bases de datos inmutables o con capacidades de 'time-travel' (como Datomic o algunas implementaciones de 'event sourcing') a menudo se basan en principios de PDS para mantener un historial completo de cambios. En el ámbito de los sistemas operativos, los 'copy-on-write filesystems' (como ZFS o Btrfs) emplean una lógica similar para crear 'snapshots' eficientes.
Para un Arquitecto de Sistemas, las Persistent Data Structures son cruciales para diseñar sistemas con alta concurrencia, resiliencia y auditabilidad. Eliminan la necesidad de 'locks' complejos en entornos multihilo, simplificando la lógica de concurrencia al garantizar que los datos nunca cambian inesperadamente. Facilitan la implementación de 'undo/redo functionality', 'time-travel debugging' y 'auditing trails' al mantener un historial completo de estados. Sin embargo, su adopción implica 'trade-offs': pueden introducir una sobrecarga de memoria y CPU debido a la creación de nuevas versiones y la gestión del 'structural sharing'. El arquitecto debe evaluar si los beneficios en simplicidad, seguridad de concurrencia y capacidades de historial superan el costo computacional, especialmente en sistemas donde la inmutabilidad y la trazabilidad son requisitos clave para la integridad de los datos o la complejidad del dominio.