Arquitetura de referência: multirregião / global

Quando os usuários estão distribuídos geograficamente ou é exigida resiliência a um desastre regional, os dados se espalham por várias regiões. Esta árvore percorre passo a passo a localidade de leitura (uma read replica em cada região), a topologia de gravação (single-leader vs multi-leader vs quorum), residência de dados/conformidade (GDPR), resolução de conflitos e os trade-offs entre RPO/RTO e latência. A verdade básica: por causa das leis da física, baixa latência, consistência forte e gravações multirregião não podem ser plenamente alcançadas ao mesmo tempo; um trade-off deliberado é obrigatório.

Por que ir para multirregião: localidade de leitura, gravações/resiliência ou conformidade?

Uma arquitetura multirregião é cara e complexa; esclareça a motivação. Você quer baixa latência de leitura para usuários distantes, gravações entre regiões/resiliência a desastres, ou o requisito real é que os dados fiquem em um país específico (residência legal)?

• Leituras rápidas para usuários distantes; as gravações podem ficar em uma região
• São necessárias gravações entre regiões / resiliência à perda de uma região
• Os dados devem legalmente permanecer em um país/região específico

Qual deve ser a topologia de gravação: single-leader, multi-leader ou quorum?

Para gravações entre regiões, a decisão-chave é o modelo de liderança. Todas as gravações vão para uma única região (simples, consistente, mas gravações remotas são lentas), toda região pode gravar (baixa latência de gravação, mas com conflitos), ou uma gravação é aceita com a confirmação da maioria das regiões (quorum: consistente, mas com latência adicional)?

• Uma região grava, as outras leem (simples e consistente)
• Toda região pode gravar localmente (baixa latência de gravação)
• Gravar com confirmação da maioria; a consistência vem primeiro

Recomendação: uma read replica por região (localidade de leitura)

As gravações permanecem em uma única região primária enquanto você coloca em cada região de usuários uma read replica alimentada por ela. Os usuários leem da réplica mais próxima e a latência de leitura cai; como as gravações continuam indo para um único centro, o modelo de consistência permanece simples.

Recomendação: gravações single-leader

Todas as gravações vão para uma única região líder; as outras regiões são read replicas alimentadas de forma assíncrona por esse líder. É o modelo mais simples e de consistência mais forte; não há conflitos porque há um único ponto de gravação. O preço é a alta latência de gravação a partir de regiões remotas.

Recomendação: gravações multi-leader + resolução de conflitos

Como toda região pode gravar localmente, a latência de gravação é baixa e, mesmo que uma região fique isolada, as outras continuam gravando. O preço é alto: duas regiões podem atualizar o mesmo registro de forma diferente, e você precisa projetar a resolução de conflitos.

Recomendação: gravações baseadas em quorum (confirmação da maioria)

Uma gravação é aceita quando a maioria (quorum) das regiões/réplicas a confirma; quando as leituras também vão para a maioria, o valor mais recente é garantido. É resiliente à perda de regiões e fortemente consistente; o preço é a latência de cada gravação até alcançar a maioria.

Recomendação: residência de dados / conformidade (GDPR)

Alguns dados (pessoais, de saúde, financeiros) devem legalmente permanecer dentro das fronteiras de um país/região específico (ex.: GDPR). Nesse caso, você não projeta a arquitetura em torno de 'copiar para todo lugar', mas de modo que os dados fiquem fixados geograficamente.