Los motores de almacenamiento deben decidir qué operaciones completan antes de confirmar al cliente que una escritura se ha realizado correctamente. Devolver el control tras copiar los bytes en memoria es la opción más rápida, pero un fallo de la máquina puede perder esos datos. Esperar a un SSD local mediante fdatasync() resiste caídas del proceso o del kernel, aunque no la pérdida del dispositivo o del host. Esperar a un volumen en red, a un almacén de objetos o a varios servidores de bases de datos permite sobrevivir más fallos, a costa de añadir latencia de red y de réplica.
El nombre de la llamada al sistema no revela qué fallos sobrevive el dato: un fdatasync() puede esperar a un SSD local o a un volumen remoto presentado como NVMe, con latencias y garantías muy distintas. Los diseños modernos basados en almacenes de objetos —ficheros inmutables, log estructurado (LSM) y SSD local como caché o write-ahead log— resultan especialmente interesantes porque el servicio de objetos se encarga de la durabilidad mientras el cálculo aparece y desaparece.
El artículo analiza los costes por operación (GET, PUT, DELETE) de un almacén clave-valor append-only, describe cómo una escritura llega al SSD local y cómo fdatasync() marca el punto de durabilidad real, y explica cómo varios PUT pueden compartir un único vaciado para mejorar el rendimiento sin cambiar las garantías. También aborda la ambigüedad entre el momento en que el WAL queda commiteado y el instante en que el cliente recibe la confirmación, y cómo un identificador de operación con reintentos idempotentes resuelve el problema.