Enunciado y escenario
Un SaaS global permite a los usuarios editar perfiles en cualquier región. Durante una partición de red, tanto Europa como los Estados Unidos aceptan actualizaciones para el mismo usuario; después de la recuperación, el nombre, el avatar, la zona horaria y las configuraciones de privacidad entran en conflicto. Diseña las escrituras, la replicación, la detección de conflictos, la fusión, la auditoría y la recuperación del usuario, y explica el balance (trade-off) entre disponibilidad y consistencia.
Lo que evalúa el entrevistador
- Si clasificas la consistencia según la semántica del campo en lugar de aplicar una única regla de conflicto a todo el registro.
- Si diseñas el enrutamiento regional, los metadatos de versión, el retraso de replicación y los reintentos idempotentes.
- Si manejas los campos de privacidad y seguridad que no se pueden fusionar automáticamente y proporcionas un resultado explicable.
- Si estableces un balance claro entre recuperación, costo, latencia y riesgo de pérdida de datos.
Preguntas de aclaración iniciales
- ¿Qué campos se pueden fusionar de forma independiente y cuáles involucran privacidad, identidad o seguridad y requieren serialización o confirmación humana?
- ¿El objetivo es consistencia fuerte, de sesión o eventual, y cuánto retraso de replicación pueden aceptar los usuarios?
- ¿Puede un usuario escribir activamente en múltiples regiones, o se puede fijar una región local (home region) por usuario o tenant?
- ¿Durante cuánto tiempo deben permanecer disponibles ambas versiones y qué deben ver los usuarios, soporte técnico y los auditores?
Respuesta en 30 segundos
Clasificaría la consistencia por campo: el avatar y la biografía pueden usar una fusión a nivel de campo, mientras que las configuraciones de privacidad y seguridad necesitan verificaciones de versión más estrictas. Cada escritura incluye una versión de usuario, región, ID de operación y los campos modificados, y la replicación utiliza eventos idempotentes. Usaría por defecto una región local (home region) para reducir conflictos; si se requiere multi-writer, detectaría versiones concurrentes, fusionaría campos seguros automáticamente y crearía un conflicto de revisión para campos sensibles. Persistiría registros de auditoría inmutables y ofrecería una ruta de recuperación visible para el usuario. Mediría la tasa de conflictos, el retraso de replicación, las actualizaciones perdidas y el tiempo de recuperación.
Análisis detallado
1. Clasificar la consistencia a nivel de campo
Divide el perfil en campos fusionables y campos sensibles a la seguridad. El nombre para mostrar, la biografía o el avatar pueden usar una fusión basada en la última escritura o en versiones, mientras que el correo electrónico, MFA, la visibilidad de privacidad y el estado de la cuenta pueden requerir escrituras condicionales, un único escritor o revisión humana. Esta clasificación define el modelo de datos, la interfaz de usuario y los permisos de recuperación; una marca de tiempo a nivel de fila es insuficiente.
2. Elegir enrutamiento de single-home, partition-home o multi-writer
El diseño más simple fija una región local por usuario o tenant, atiende lecturas cercanas en otros lugares y asume el control temporalmente durante una falla. Si el negocio requiere multi-writer, acepta el costo de detección y fusión de conflictos. El enrutamiento debe incluir metadatos de región y versión; la conmutación por error (failover) necesita un arrendamiento (lease) o una época (epoch) de traspaso explícita para que una región local antigua recuperada no continúe escribiendo y genere conflictos de reproducción (replay).
3. Diseñar versiones, eventos e idempotencia
Almacena un vector de versiones, la región, el tiempo lógico y el último ID de operación por campo o grupo de campos. Una escritura condicional verifica que la versión base del cliente siga siendo válida; los reintentos se deduplican mediante el ID de operación. Los eventos de replicación contienen la versión anterior, la nueva versión y los campos modificados, de modo que las entregas duplicadas, fuera de orden y retrasadas no puedan aplicar ni sobrescribir un cambio dos veces.
4. Definir la detección de conflictos y la fusión automática
Dos versiones entran en conflicto cuando ninguna incluye a la otra. Los campos disjuntos se pueden fusionar; el mismo campo sigue una regla de negocio como prioridad de región local, último escritor o revisión explícita. No trates el tiempo de reloj físico (wall-clock time) como la intención del usuario: el desvío de reloj (clock skew) puede hacer que gane el contenido más antiguo. Registra la regla, las versiones de origen y el resultado de cada fusión.
5. Proteger los campos de privacidad y seguridad
La visibilidad de privacidad, el correo electrónico, los métodos de inicio de sesión y MFA no deben usar la regla común de que la última escritura gana (last-write-wins). Exige escrituras condicionales, autorización de región local o revisión humana, y mantén la visibilidad de manera conservadora durante un conflicto. Las API de recuperación deben autenticar al operador y verificar el motivo y los permisos para que "resolver conflicto" no se convierta en una vía de escalamiento de privilegios.
6. Hacer que la recuperación y la observabilidad sean prioritarias
Conserva las versiones previas y posteriores al conflicto, la cadena de eventos y la decisión de fusión, y permite que los usuarios deshagan los cambios o elijan una versión. Monitorea la tasa de conflictos, el retraso de replicación, las versiones atascadas, las actualizaciones perdidas, el tiempo de resolución manual y los cambios de región. Realiza pruebas de aislamiento regional, reactivación de regiones locales antiguas (resurrection), eventos duplicados y reproducción para que la recuperación no genere una segunda sobrescritura.
Una respuesta sólida y completa
Clasificaría la consistencia por campo y aplicaría reglas condicionales o de escritor único más estrictas a los campos de privacidad y seguridad. Establecería por defecto una región local para el usuario con lecturas cercanas; si se requiere multi-writer, incluiría la región, la versión, el ID de operación y el conjunto de campos modificados en cada evento, haciendo que la replicación sea idempotente y segura ante reordenamientos. Detectaría versiones concurrentes, fusionaría automáticamente campos disjuntos y usaría reglas de negocio o revisión del usuario para el mismo campo; nunca trataría el tiempo de reloj físico como intención. Escribiría las versiones, las reglas de fusión y los operadores en un registro de auditoría, monitorearía la tasa de conflictos, el retraso, las actualizaciones perdidas y el tiempo de recuperación, y simularía la reactivación de regiones locales antiguas y eventos duplicados.
Modos de falla comunes
- Aplicar una única regla de last-write-wins a nivel de registro que sobrescriba cambios de privacidad o seguridad.
- Decir "usar un vector de versiones" sin explicar la granularidad del campo, el costo de almacenamiento y la experiencia del usuario tras un conflicto.
- Ignorar la replicación duplicada, desordenada o retrasada y la reactivación de regiones locales antiguas, provocando otra sobrescritura durante la recuperación.
- Omitir los ID de operación, el historial de auditoría y una ruta de deshacer para el usuario, haciendo que las fusiones sean inexplicables e irreparables.
- Discutir únicamente la disponibilidad y la latencia sin medir las actualizaciones perdidas, la tasa de conflictos y el costo manual.
Preguntas de seguimiento y extensiones
Seguimiento 1: ¿Por qué no usar last-write-wins en todas partes?
Es simple y converge, pero el tiempo de reloj físico no expresa la intención del usuario y el desvío de reloj puede permitir que gane contenido más antiguo. Puede ser aceptable para campos de bajo riesgo; la privacidad, la seguridad y el contenido de alto valor necesitan escrituras condicionales, un escritor local o resolución explícita de conflictos.
Seguimiento 2: ¿Afecta una región local a la disponibilidad?
Añade latencia de escritura entre regiones y requiere una toma de control durante una falla de la región local, pero reduce en gran medida los conflictos y la complejidad operativa. Elige una región local por tenant, proporciona una época de toma de control temporal y evalúa los objetivos de disponibilidad junto con los requisitos de seguridad de los datos.
Seguimiento 3: ¿Cómo debería mostrar la interfaz de usuario un conflicto?
Muestra el campo, ambas fuentes y los tiempos de actualización, y explica por qué se necesita una elección. Mantén los campos sensibles de forma conservadora y evita exponer términos internos de región o base de datos. Proporciona opciones de deshacer, reintentar y canales de soporte, y registra la elección del usuario.
Seguimiento 4: ¿Cómo se lee cuando la replicación tiene un retraso significativo?
Devuelve una marca de agua (watermark) de versión o región para que los clientes conozcan el nivel de actualización. Enruta la lectura posterior a la escritura (read-after-write) para flujos críticos a la región de escritura, mientras que las lecturas ordinarias aceptan consistencia eventual. Emite alertas, limita los cambios de alto riesgo o redirige a los usuarios a la región local cuando el retraso supere un umbral.