Corrección de datos distribuidos
Comienza con el contrato
Escribe el invariante, su alcance y los fallos que debe sobrevivir. "Un pedido se cobra como máximo una vez" es útil; "fuerte consistencia" es insuficiente. Identifica el registro autoritativo, las vistas derivadas, los actores y cada límite de commit/acknowledgment. Pregunta si los clientes necesitan read-your-writes, orden causal, operaciones linealizables, transacciones serializables o simplemente convergencia eventual.
Procedimiento de revisión
- Dibuja la ruta de escritura, incluyendo el commit de la base de datos, el acknowledgment del broker y los efectos secundarios externos. Registra lo que garantiza cada respuesta exitosa después de un fallo de proceso, pérdida de máquina o failover de réplica. Un timeout significa resultado desconocido, no necesariamente ejecución fallida.
- Enumera las ventanas de fallo antes y después de cada paso duradero. Para cada una, reproduce la operación y verifica el invariante. Prueba intentos concurrentes así como reintentos secuenciales. Usa el registro de fallos.
- Mantén un efecto de negocio y su marcador de deduplicación en una misma transacción cuando compartan una base de datos. Para eventos salientes, considera un outbox transaccional. Para efectos remotos, requiere un contrato de idempotencia duradero del proveedor o una máquina de estado de reconciliación. Las garantías de entrega del broker se detienen en su límite de transacción documentado.
- Identifica el alcance del ordenamiento: clave, partición, flujo o global. Elige el alcance más estrecho que preserve el invariante. Un log particionado ordena sus particiones; no ordena automáticamente eventos relacionados en diferentes particiones.
- Para replicación y failover, inspecciona elección, fencing, política de acknowledgment
y recuperación.
R + W > Nda intersección de conjuntos bajo membresía fija; por sí solo no establece linealizabilidad. Consulta consistencia. - Para sharding, verifica localidad de transacciones, claves calientes, rebalanceo y aplicación de unicidad. Mide el shard más ocupado, no solo el throughput agregado.
- Produce el contraejemplo más pequeño para una garantía dudosa y una prueba que lo ejercite. Separa las garantías requeridas del estancamiento aceptable.
Salida de la revisión
Devuelve: invariante → supuestos → línea de tiempo de fallos → garantía violada → corrección mínima → costos → validación. Incluye un camino de recuperación para datos ya inconsistentes. Nombra cualquier comportamiento que dependa de una versión de base de datos, broker o proveedor.
Verifica antes de recomendar
- ¿Puede una solicitud reintentada reutilizar su ID de operación estable con parámetros cambiados?
- ¿Necesita un titular de lease un token de fencing monótonamente creciente impuesto por el recurso? La expiración del lease por sí sola no puede detener un proceso pausado.
- ¿Pueden las réplicas servir valores obsoletos inmediatamente después de una escritura exitosa?
- ¿Expiran los tombstone o los registros de deduplicación antes del horizonte de reproducción?
- ¿Requiere un invariante de múltiples registros una transacción o coordinación explícita?
Alcance y referencias
Cobertura parcial alineada con Designing Data-Intensive Applications, 2da ed. (Kleppmann y Riccomini). Estos procedimientos originales usan notas de curso públicas del autor y documentación primaria adicional; el libro completo no estaba disponible. Lee fuentes para atribución exacta. Esta habilidad no proporciona una implementación de consenso ni asume tolerancia a fallos bizantinos.