A região que você escolhe controla onde a Bird armazena e processa os dados da sua organização. Ela também afeta quais regras de privacidade transfronteiriças se aplicam.
Onde meus dados ficam?
Em uma única região, escolhida quando a organização é criada.
Toda organização Bird recebe uma região no cadastro. us1 são os Estados Unidos e eu1 é a União Europeia, e a documentação de regiões descreve o que essa atribuição abrange:
Every organization is assigned a region at signup. The region is detected from your location, can be changed before you confirm, and is immutable in v1. The workspace, API keys, messages, recipient data, and event logs remain in that region. They are never replicated across regions.
A frase a observar é "never replicated". Um compromisso de residência que permitisse uma cópia em outro lugar para redundância ou análise não seria um. Aqui o plano de dados é genuinamente separado por região, e é também por isso que a escolha é imutável: mover uma organização entre regiões não é uma configuração, é uma migração que a versão atual da API não oferece.
Como isso é aplicado?
Na credencial e no roteamento, para que um erro falhe de forma visível.
Não existe um endpoint global único para o plano de dados. Cada região tem seu próprio host, e uma chave API indica sua região no prefixo: uma chave bk_eu1_ pertence a eu1. Os SDKs e a CLI leem o prefixo e escolhem o host sem necessidade de configuração.
O que acontece quando uma solicitação vai para o lugar errado é a parte interessante:
A request that reaches the wrong region is rejected with
421 Misdirected Requestinstead of being forwarded. The error message names the correct host
Recusar em vez de encaminhar é a decisão de design que torna a residência verificável. Uma plataforma que silenciosamente fizesse proxy de uma solicitação mal direcionada seria conveniente, mas também significaria que uma solicitação carregando dados pessoais teria cruzado uma fronteira sem ninguém perceber. Aqui isso não pode acontecer: a solicitação falha, e o erro indica o host a ser usado.
Toda resposta também traz um header X-Bird-Region indicando a região que a atendeu, para que você possa confirmar onde a chamada realmente chegou em vez de confiar na configuração.
O que não é vinculado à região?
Autenticação e administração de conta, e a documentação diz isso explicitamente em vez de deixar implícito:
Only authentication and account administration (
/v1/auth,/v1/admin) operate on globally replicated data, which is why they are served from the non-region hostplatform.bird.com.
Isso vale saber em vez de passar batido. Login e gerenciamento de conta lidam com dados de identidade que precisam funcionar de qualquer lugar, então essas duas superfícies são globais por design, enquanto tudo relacionado a mensagens e destinatários não é. Se você está documentando seus próprios fluxos de dados, essa divisão é a fronteira a traçar.
A residência decide para onde minhas mensagens vão?
Não, e confundir os dois conceitos leva à conclusão errada em ambas as direções.
Residência é onde seus dados são armazenados e processados. Entrega é sobre onde seus destinatários estão, o que é regido por cobertura, regras locais e sanções. Uma organização eu1 pode enviar para destinatários em qualquer lugar onde a Bird opera, e uma organização us1 pode enviar para destinatários europeus. Países e restrições aceitos cobre o lado da entrega.
O que a residência decide é onde o registro daquela mensagem fica depois: a própria mensagem, os dados do destinatário, o log de eventos. Esse registro geralmente é o que uma questão de proteção de dados realmente aborda.
O que devo decidir antecipadamente?
A região, porque é a única parte disso que você não pode revisitar.
Como a atribuição é imutável depois de confirmada, a seleção de região pertence a qualquer processo que crie sua organização de produção, junto com tudo o mais que é decidido uma vez. Uma organização de teste criada na região errada é um pequeno incômodo; uma de produção é uma migração.
Duas coisas relacionadas para definir ao mesmo tempo, já que costumam aparecer juntas na maioria das revisões: o acordo de processamento de dados que rege a relação, e onde o provedor publica sua lista de subprocessadores, já que um subprocessador em outra jurisdição é uma questão de transferência que a residência sozinha não responde.
Em resumo
A residência é uma propriedade da organização, não de uma solicitação.
A região é atribuída no cadastro, pode ser alterada antes da confirmação e é imutável depois disso na versão atual da API.
Nada é replicado entre regiões.
Espaços de trabalho, chaves, mensagens, dados de destinatários e logs de eventos permanecem em uma única região, e é isso que torna um compromisso de residência significativo.
A chave da API carrega sua região, e um host errado é recusado.
Uma solicitação que chega à região errada recebe
421 Misdirected Requestindicando o host correto, em vez de ser silenciosamente encaminhada.Duas superfícies são deliberadamente globais.
Autenticação e administração de conta operam sobre dados replicados, e por isso respondem em um host independente de região.