¿Cómo afecta la replicación de base de datos al diseño?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

La replicación copia cambios de una primaria a una o más réplicas, lo que da capacidad de lectura, un standby para failover y copias en otras regiones. La replicación asíncrona implica retraso en las réplicas, así que una lectura tras una escritura puede no verla; la síncrona elimina ese retraso para la réplica confirmada a costa de latencia de escritura y disponibilidad si la réplica cae. De ahí las decisiones de diseño: qué lecturas toleran obsolescencia y van a réplicas, cuáles deben leer la primaria o usar enrutado leer-tus-escrituras, cómo la aplicación descubre la nueva primaria tras un failover y reintenta transacciones en vuelo, y cómo se monitorizan retraso y salud de la replicación para atrapar una rotura silenciosa antes de un failover a datos obsoletos.

Ejemplo

Una plataforma de comercio enruta la navegación de productos a réplicas y todo lo del checkout a la primaria; tras actualizar la dirección, la sesión se fija a la primaria durante 10 segundos para que la página de confirmación la refleje. El failover está automatizado con un endpoint virtual, el pool de conexiones descarta conexiones al cambiar la primaria y una alerta salta cuando el retraso supera 5 segundos, lo que una vez reveló una réplica que había dejado de aplicar cambios en silencio.

Errores frecuentes

• Enviar todas las lecturas a réplicas y mostrar a los usuarios sus propias escrituras como ausentes.
• Suponer que el failover es instantáneo y no manejar los segundos de fallos de escritura durante él.
• Ignorar el retraso de replicación hasta que un failover promueve una réplica minutos por detrás.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.