Replicação consiste em manter cópias dos mesmos dados em mais de uma máquina, permitindo que o serviço continue operando caso uma máquina falhe e que suporte um volume de tráfego maior do que uma única máquina conseguiria processar.
Para ilustrar isso na prática, utilizaremos um serviço simples de perfil de usuário que suporta as operações GET /profile/{user_id} e PUT /profile/{user_id} para ler e atualizar o nome, a URL da foto e as configurações de um usuário.
Um único servidor é suficiente até o momento em que o banco de dados de perfis se torna um ponto único de falha e um gargalo de vazão, pois todas as operações de leitura e escrita passam a depender de essa máquina estar operacional e rápida.
A próxima etapa estabelece nossa configuração de referência, permitindo que, em lições posteriores, possamos submetê-la a testes de estresse e observar onde ela falha.
Nesse cenário base, os clientes chamam o serviço de API, e o serviço de API lê e grava em um único banco de dados; assim, uma falha no banco de dados interrompe tanto as leituras quanto as gravações, e um pico de tráfego sobrecarrega uma única CPU e um único disco.
É essa pressão que torna a replicação um tópico de projeto em entrevistas, pois o entrevistador focará no que acontece durante falhas e sob carga, e não em como um endpoint é implementado.
A replicação não é uma funcionalidade única. Trata-se de um conjunto de escolhas que dependem do que o sistema deve garantir quando partes dele falham.
No caso de um serviço de perfil, o entrevistador geralmente começa verificando se somos capazes de levantar os poucos requisitos que alteram o padrão de replicação, antes de mencionar qualquer tecnologia específica.
Os parâmetros a serem definidos correspondem diretamente aos fluxos de leitura e escrita.
Uma vez definidos esses pontos, a replicação deixa de ser um conceito abstrato e passa a ser um contrato concreto — como determinar se a requisição GET /profile pode retornar uma foto antiga por alguns segundos após a conclusão bem-sucedida de um PUT /profile.
Com os requisitos estabelecidos, o projeto mínimo de replicação adiciona exatamente uma cópia adicional do banco de dados e define como as atualizações são propagadas entre elas.
Por enquanto, mantemos a semântica da aplicação inalterada. Os clientes continuam interagindo com uma única camada de API, e essa camada ainda realiza uma operação lógica de escrita que não deve resultar, silenciosamente, em versões conflitantes.