Last-Write-Wins (LWW) es una política de resolución de conflictos que se aplica en entornos distribuidos donde múltiples nodos pueden intentar modificar el mismo dato concurrentemente. Cuando se detecta una inconsistencia o un conflicto de escritura, LWW resuelve la disputa seleccionando la versión del dato que posee el timestamp (marca de tiempo) más reciente. Este timestamp puede ser lógico (ej. un vector clock simplificado o un contador de versión) o físico (ej. la hora del sistema). La premisa es que la escritura más 'reciente' es la que refleja el estado deseado por el usuario o la aplicación, descartando las escrituras 'más antiguas'.
LWW es ampliamente utilizado en sistemas de almacenamiento NoSQL y bases de datos distribuidas que priorizan la disponibilidad y la tolerancia a particiones (AP en el teorema CAP) sobre la consistencia fuerte. Ejemplos concretos incluyen: Amazon DynamoDB, donde LWW es una estrategia de resolución de conflictos por defecto para ciertos tipos de datos; Apache Cassandra, que utiliza LWW basado en timestamps de escritura para resolver conflictos entre réplicas; y Riak KV, que también emplea LWW como una de sus estrategias configurables. En estos sistemas, cada escritura se asocia con un timestamp, y durante la fase de 'read repair' o 'hinted handoff', el nodo coordinador o los nodos de réplica comparan los timestamps para determinar la versión canónica.
Para un arquitecto, LWW es una herramienta poderosa para diseñar sistemas de alta disponibilidad y baja latencia, pero conlleva trade-offs significativos. Su principal ventaja es la simplicidad y la eficiencia, ya que no requiere coordinación compleja ni algoritmos de consenso costosos (como Paxos o Raft) para resolver conflictos, lo que permite escrituras rápidas y una alta disponibilidad. Sin embargo, su principal desventaja es la pérdida potencial de datos: si dos escrituras ocurren casi simultáneamente y la escritura 'más antigua' contiene información crítica que la 'más nueva' no tiene (ej. una actualización parcial), LWW la descartará. Esto puede llevar a estados inconsistentes o a la pérdida de actualizaciones lógicas. Un arquitecto debe evaluar cuidadosamente si la semántica de la aplicación puede tolerar esta pérdida de datos o si se necesitan mecanismos adicionales (como 'merge functions' o 'CRDTs') para complementar LWW, especialmente en casos donde la 'última escritura' no siempre es la 'correcta' desde una perspectiva de negocio.