O que é replicação de banco de dados multi-região?

A replicação multi-região é uma topologia de banco que copia dados entre regiões geográficas para reduzir latência de leitura e sobreviver a quedas. O inimigo é a física: uma ida e volta cruzando um oceano custa dezenas de milissegundos antes de o banco fazer qualquer trabalho, e padrões de requisição tagarelas pagam isso repetidamente. A replicação leva os dados até os usuários — e imediatamente levanta as perguntas que definem o tema: quem aceita escritas, o quão desatualizadas as leituras podem estar, e se você já precisa de algo disso.

Principais pontos

Meça antes de replicar

Antes de qualquer decisão de topologia, obtenha o número do qual ela depende — quanto uma ida e volta custa de fato aos seus usuários, por região:

// JavaScript / Node.js — Back4app JS SDK
// Latency probe: measure what users in this region actually feel
const probe = new Parse.Query('HealthCheck');
probe.limit(1);

const started = Date.now();
await probe.first();               // one lightweight read
const readMs = Date.now() - started;

const sample = new Parse.Object('LatencySample');
sample.set('clientRegion', 'eu');  // where this client runs
sample.set('readMs', readMs);
await sample.save();               // writes always travel to the primary

console.log(`read: ${readMs} ms — reads can be served locally,`);
console.log('writes pay the distance to the primary region');

// Flutter / Dart — Back4app Flutter SDK
// Latency probe: measure what users in this region actually feel
final probe = QueryBuilder<ParseObject>(ParseObject('HealthCheck'))
  ..setLimit(1);

final started = DateTime.now();
await probe.query();               // one lightweight read
final readMs = DateTime.now().difference(started).inMilliseconds;

final sample = ParseObject('LatencySample')
  ..set('clientRegion', 'eu')      // where this client runs
  ..set('readMs', readMs);
await sample.save();               // writes always travel to the primary

print('read: $readMs ms — reads can be served locally,');
print('writes pay the distance to the primary region');

// iOS / Swift — Back4app Swift SDK
// Latency probe: measure what users in this region actually feel
let probe = HealthCheck.query().limit(1)

let started = Date()
probe.first { result in            // one lightweight read
  let readMs = Int(Date().timeIntervalSince(started) * 1000)

  var sample = LatencySample()
  sample.clientRegion = "eu"       // where this client runs
  sample.readMs = readMs
  sample.save { _ in               // writes always travel to the primary
    print("read: \(readMs) ms — reads can be served locally,")
    print("writes pay the distance to the primary region")
  }
}

// Android / Kotlin — Back4app Android SDK
// Latency probe: measure what users in this region actually feel
val probe = ParseQuery.getQuery<ParseObject>("HealthCheck")
probe.limit = 1

val started = System.currentTimeMillis()
probe.getFirstInBackground { _, e ->      // one lightweight read
    val readMs = System.currentTimeMillis() - started

    val sample = ParseObject("LatencySample")
    sample.put("clientRegion", "eu")      // where this client runs
    sample.put("readMs", readMs)
    sample.saveInBackground {             // writes travel to the primary
        println("read: $readMs ms — reads can be served locally,")
        println("writes pay the distance to the primary region")
    }
}

Quando os números justificam réplicas, a maquinaria é padrão — aqui como replicação lógica do PostgreSQL, com o lag como fato consultável de primeira classe:

-- No primário (região A): publique as mudanças
CREATE PUBLICATION app_pub FOR ALL TABLES;

-- Na réplica (região B): assine e receba o stream
CREATE SUBSCRIPTION app_sub
  CONNECTION 'host=primary.internal dbname=app'
  PUBLICATION app_pub;

-- O número que define a sua janela de desatualização:
SELECT application_name,
       now() - reply_time AS approx_lag
FROM pg_stat_replication;

Um primário, muitas regiões — o fluxo e o lag

Esta é a topologia cavalo de batalha — replica sets em bancos de documentos, réplicas em streaming nos relacionais — e os seus dois custos estão visíveis no diagrama. Latência de escrita: toda escrita viaja até a região do primário, então usuários distantes pagam a travessia do oceano justamente nas ações que mudam dados. Lag: streams entre regiões são assíncronos — replicação síncrona somaria a ida e volta completa a cada commit —, então as réplicas ficam para trás de milissegundos a segundos, e as leituras podem estar desatualizadas nessa medida. A mordida clássica é o read-your-own-writes: salvar, atualizar contra a réplica local, não ver nada. Os remédios são política de roteamento, não mágica — mande as leituras pós-escrita do usuário para o primário, ou fixe a sessão dele até a réplica alcançar.

O passo seguinte — múltiplos primários de escrita — localiza também as escritas, mas compra a mercadoria mais difícil do teorema CAP: escritas concorrentes e conflitantes em regiões diferentes precisam ser detectadas e resolvidas. Cargas livres de conflito (dados por usuário, streams append-only) vestem bem isso; estado mutável compartilhado veste mal.

Região única vs. réplicas de leitura vs. multi-primário

A leitura honesta da tabela: cada coluna à direita troca simplicidade por localidade. A maioria dos produtos deveria ficar na coluna mais à esquerda que atenda aos seus números de latência e disponibilidade — e muitos descobrem que um CDN para os ativos mais uma região de banco bem escolhida já atendem, já que o peso estático costuma dominar o tempo de carregamento percebido.

Casos de uso comuns

• Produtos globais de leitura intensa. Catálogos, conteúdo, dashboards — tráfego dominado por navegação, em que réplicas regionais convertem oceanos em milissegundos de um dígito.
• Bases regionais com cauda global. Primário na região do mercado principal, réplicas onde vive a cauda.
• Disaster recovery e failover. Uma cópia atual em outra região como história de disponibilidade — valiosa mesmo quando a latência nunca justificou réplicas.
• Residência de dados. Manter os dados de determinados tenants em jurisdições específicas — particionamento com consciência de tenant por região, um primo de política da replicação.
• Seguro de portabilidade. Replicar sobre engines open-source mantém a topologia sua — um hedge silencioso contra vendor lock-in que bancos globais proprietários não oferecem.

Você deveria ir multi-região? Matriz de decisão

A ordem do diagnóstico importa: perfile as consultas e adicione índices primeiro, agrupe os padrões de requisição tagarelas em segundo, coloque os ativos estáticos num CDN em terceiro, posicione bem a sua região única em quarto — e replique em quinto, quando a latência restante for genuinamente geográfica. Times que pulam direto para o quinto herdam problemas de sistemas distribuídos enquanto o gargalo real era uma consulta sem índice.

Limitações e trade-offs

• O lag é estrutural. Streams assíncronos ficam para trás por projeto; toda leitura em réplica carrega uma janela de desatualização que o seu produto precisa tolerar ou contornar por roteamento.
• As escritas continuam cruzando o oceano. Topologias de primário único localizam apenas as leituras — o checkout, o post, a reserva continuam pagando a distância.
• Failover é um procedimento, não uma promessa. Promoção, cutover e o risco de perder escritas não replicadas (RPO de novo) — faça o simulado antes de acreditar.
• Multi-primário importa conflitos. Escritas concorrentes no mesmo registro em duas regiões precisam ser mescladas de algum jeito; “a última escrita vence” é uma política de perda de dados vestida de padrão.
• O custo escala com as cópias. Armazenamento, tráfego entre regiões e a atenção de engenharia de mais um sistema distribuído — precificados com honestidade, por região.
• Replicação não é backup. Toda réplica copia fielmente os seus erros em segundos; point-in-time recovery existe para a classe de falha que a replicação espalha.

Multi-região e latência no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A mecânica de replicação mora abaixo do seu código: o banco gerenciado roda sobre infraestrutura replicada com failover tratado pela plataforma, e a escolha de região na criação do app coloca o primário onde os seus usuários estão — a decisão de latência de maior alavancagem que este artigo recomenda tomar primeiro. Como a stack é open source de ponta a ponta, a topologia continua portátil: o mesmo Parse Server e os mesmos engines de banco rodam onde quer que você venha a precisar de uma região que o menu da plataforma não liste.