SPFresh (Strongly Persistent Freshness) es un protocolo o mecanismo diseñado para asegurar la "frescura" (freshness) de los datos en sistemas distribuidos, particularmente en escenarios donde los clientes interactúan con cachés o réplicas. Su objetivo principal es garantizar que, tras una operación de escritura exitosa en el sistema, cualquier lectura subsiguiente de ese mismo dato por cualquier cliente refleje la versión más reciente y confirmada. Esto previene problemas de coherencia como la lectura de datos obsoletos (stale reads) que pueden surgir en sistemas con replicación asíncrona o cachés distribuidas, donde la propagación de actualizaciones no es instantánea.
Aunque SPFresh no es un término estandarizado o un algoritmo único con una implementación canónica universalmente reconocida como "Bloom Filter" o "Raft", el concepto subyacente de garantizar la frescura fuerte se implementa de diversas formas en sistemas distribuidos. Por ejemplo, bases de datos distribuidas como Google Spanner logran una coherencia externa fuerte (external consistency) que inherentemente satisface los requisitos de SPFresh, utilizando relojes de precisión y protocolos de commit distribuido. Sistemas de almacenamiento en la nube como Amazon S3 ofrecen "read-after-write consistency" para nuevas escrituras en objetos, que es una forma de SPFresh. En sistemas de caché distribuidos, se pueden emplear mecanismos como invalidación de caché basada en versiones o "lease-based caching" para asegurar que los clientes no sirvan datos obsoletos después de una actualización.
Para un Arquitecto de Sistemas, SPFresh es un concepto crítico porque impacta directamente la fiabilidad y la experiencia del usuario de una aplicación. La decisión de implementar o requerir SPFresh implica trade-offs significativos: a menudo se logra a expensas de la latencia y la disponibilidad. Garantizar una frescura fuerte puede requerir coordinación global, commits distribuidos o invalidaciones de caché síncronas, lo que aumenta la latencia de escritura y lectura, y puede reducir la disponibilidad durante fallos de red o nodos. Un arquitecto debe evaluar si la aplicación realmente necesita esta garantía de frescura estricta (ej. transacciones financieras, sistemas de control) o si una coherencia eventual o "eventual consistency" es aceptable para mejorar el rendimiento y la escalabilidad (ej. feeds de redes sociales, catálogos de productos). La elección impacta la complejidad del diseño, los costos operativos y la resiliencia del sistema.