La replicación consiste en mantener copias de los mismos datos en más de una máquina, de modo que el servicio pueda seguir funcionando si una máquina falla y pueda gestionar un volumen de tráfico mayor del que soportaría una sola máquina.
Para ilustrar esto de forma concreta, utilizaremos un servicio sencillo de perfiles de usuario que admite las operaciones GET /profile/{user_id} y PUT /profile/{user_id} para leer y actualizar el nombre, la URL de la foto y la configuración de un usuario.
Un único servidor es suficiente hasta que la base de datos de perfiles se convierte en un punto único de fallo y en el límite máximo de rendimiento, ya que todas las operaciones de lectura y escritura dependen de que esa máquina funcione correctamente y con rapidez.
La siguiente vista establece nuestra línea base, lo que permitirá que en lecciones posteriores sometamos el sistema a pruebas de estrés y observemos dónde se produce el fallo.
En ese escenario base, los clientes invocan al servicio de API y este lee y escribe en una única base de datos; por tanto, un fallo en la base de datos interrumpe tanto las operaciones de lectura como las de escritura, y un pico de tráfico satura una única CPU y un único disco.
Esa es la razón por la que la replicación se convierte en un tema de diseño en las entrevistas: el entrevistador se centrará en qué sucede durante los fallos y bajo carga, en lugar de en cómo se implementa un endpoint concreto.
La replicación no es una funcionalidad única, sino un conjunto de decisiones que dependen de lo que el sistema deba garantizar cuando fallan algunos de sus componentes.
En el caso de un servicio de perfiles, el entrevistador suele comenzar evaluando si somos capaces de solicitar los pocos requisitos que modifican el patrón de replicación, antes de mencionar ninguna tecnología específica.
Los parámetros que deben definirse se corresponden directamente con los flujos de lectura y escritura.
Una vez establecidos estos puntos, la replicación deja de ser una idea abstracta y se convierte en un contrato concreto; por ejemplo, determinar si se permite que GET /profile devuelva una foto antigua durante unos segundos después de que PUT /profile se haya completado con éxito.
Una vez definidos los requisitos, el diseño mínimo con replicación añade exactamente una copia más de la base de datos y determina cómo se propagan las actualizaciones entre ellas.
Por ahora, mantenemos inalterada la semántica de la aplicación. Los clientes siguen interactuando con una única capa de API, y dicha capa sigue emitiendo una operación de escritura lógica que no debe derivar silenciosamente en versiones en conflicto.