Lance uma região de dados na UE em 90 dias: um playbook para CTOs após a decisão da Fastmail

Seu próximo contrato enterprise pode cair por causa de uma única pergunta: “Onde os dados ficam?” A Fastmail acaba de anunciar uma região de dados na UE. Não foi por diversão; foi porque os clientes exigiram. Se você vende para a Europa e ainda opera apenas uma região nos EUA, está deixando dinheiro na mesa e entregando RFPs para concorrentes que conseguem responder “Frankfurt”.

Este post traz um playbook de 90 dias para colocar de pé uma região de dados na UE sem reescrever tudo do zero. É opinativo, testável e projetado para um time de scale‑up com 8–20 engenheiros de backend. Você vai separar planos de controle e de dados, fixar tenants a regiões, manter as chaves de criptografia por região e provar (não prometer) que PII nunca sai da UE.

O que “residência de dados” realmente significa (escolha seu nível)

Antes de começar a provisionar, defina o escopo de residência. Seu time jurídico vai agradecer e sua arquitetura não vai desviar.

• Residência de armazenamento: PII do cliente em repouso armazenada somente na região (BD, storage de objetos, backups).
• Residência de processamento: A computação que toca PII roda na região (APIs, jobs, ferramentas de suporte).
• Residência de acesso: O acesso humano à PII é restrito a colaboradores com contexto regional aprovado e controles auditáveis.
• Residência de dependências: Subprocessadores usados com PII são fixados por região e divulgados no seu DPA.

A maioria dos clientes que pedem “residência de dados na UE” quer pelo menos armazenamento e processamento. Muitos aceitam backups entre regiões criptografados se as chaves de criptografia nunca saírem da UE. Alguns exigem isolamento rígido (sem fluxos entre regiões, mesmo criptografados). Decida seu alvo e escreva isso.

Uma classificação de dados simples que não desaba sob carga

• P0 (PII/segredos centrais): nomes, e‑mails, telefones, endereços físicos, documentos oficiais, tokens de acesso, conteúdo bruto enviado por usuários.
• P1 (soft PII/dados de negócio): metadados de recursos, contadores de uso, estado de workflow que não é diretamente identificável, mas torna‑se sensível quando unido a P0.
• P2 (telemetria operacional): logs, métricas, traces, agregados de billing, analytics de produto com P0 removido ou salgado além de reversão.

Política: P0 e P1 nunca cruzam a fronteira da região. P2 pode ser exportado desde que transformações irreversíveis aconteçam antes da saída, dentro da região.

Estratégia de tenancy: comece simples, não se arrependa depois

Você tem três opções. Só uma entrega em 90 dias sem te encurralar.

• Tenancy fixado por organização (recomendado): Cada organização cliente seleciona uma região no cadastro ou durante a migração. Todo o seu P0/P1 vive e é processado naquela região. É o mais limpo para B2B. Fácil de raciocinar, auditar e vender.
• Tenancy fixado por usuário: Residência por usuário dentro de uma organização global. Parece bom para times “híbridos”, mas espalha complexidade em autenticação, colaboração e relatórios. Não comece por aqui.
• Tenancy fixado por objeto: Cada pedaço de conteúdo escolhe uma região. Ótimo para redes de conteúdo consumer; péssimo para auditoria enterprise. Evite, a menos que seu produto seja inerentemente de distribuição global de conteúdo.

Escolha fixo por organização e siga em frente. Você pode adicionar exceções por usuário depois se um cliente gigante exigir.

Plano de controle vs. plano de dados: o único limite que escala

Sua arquitetura atual provavelmente mistura ambos. Separe‑os:

• Plano de controle global: Diretório de tenants, metadados de plano/faturamento, feature flags, tabela de roteamento (org → região) e sem P0. Ele orquestra; nunca armazena PII.
• Planos de dados regionais (UE, EUA, …): Frontends de API, bancos de dados, storage de objetos, busca, filas, jobs batch — tudo que toca P0/P1. Eles não conversam entre si, exceto por canais bem definidos e auditados para exportações de P2 ou DR opcional criptografado.

Esse é o padrão ao qual a Fastmail e outros provedores SaaS maduros convergem porque alinha incentivos: auditores inspecionam os planos de dados; o plano de controle permanece simples e global.

A construção em 90 dias: um blueprint concreto

Dias 0–15: Inventário, política e ganchos de schema

• Faça o inventário de subprocessadores: Liste todo fornecedor que hoje vê PII (e‑mail, suporte, analytics, APM, rastreamento de erros). Marque por cor conforme capacidade na UE.
• Escolha sua região na UE: AWS eu‑central‑1 (Frankfurt) ou eu‑west‑1 (Ireland) são comuns. Latência ~20–40 ms a partir dos principais hubs da UE. Não complique.
• Adicione região ao schema de tenancy: A tabela de organizações recebe region_code (p. ex., EU, US). Faça chaves estrangeiras de todas as tabelas P0/P1 de volta para org. Se você é multi‑tenant, adicione CHECK (region_code = current_setting('app.region')) por schema ou use Row Level Security (RLS) vinculada a app.region. Torne impossível gravar entre regiões por acidente.
• Defina agora a postura de DR: Opção A (estrita): nenhum cópia entre regiões; aceite DR apenas regional. Opção B (balanceada): replique backups criptografados entre regiões com chaves que nunca saem da região de origem. Escreva isso no seu DPA e nos seus runbooks.

Dias 16–35: Levante a stack na UE (paridade, não perfeição)

• Banco de dados: Cluster Postgres ou MySQL separado na UE. Sem replicação lógica a partir dos EUA. Mesmos schemas, mesmas extensões. Mire p95 de latência de leitura de API ≤50 ms dentro da região.
• Storage de objetos: Buckets regionais (S3 eu‑central‑1/eu‑west‑1, GCS europe‑west). Use Object Lock e regras de ciclo de vida. Não replique objetos brutos para fora da região, a menos que a política de DR permita e as chaves permaneçam presas à UE.
• KMS/chaves: Chaves KMS por região. Não exporte chaves. Se fizer DR entre regiões criptografado, use múltiplas cópias do ciphertext com chaves não exportáveis presas à UE. SLA de rotação de chaves: 90 dias; rotação de emergência: 24 horas.
• Filas/jobs: SQS/PubSub regionais e workers regionais. Nada de filas globais para trabalho P0/P1. Marque jobs com org_id e afirme a região ao consumir.
• Busca: Rode um índice regional (OpenSearch/Elasticsearch) alimentado pelo BD da UE. Nada de busca global para tenants da UE. Se precisar unificar, faça com resumos P2.
• Feature flags: Escolha um fornecedor com residência de dados na UE ou faça self‑host de um serviço simples de flags (OpenFeature + Redis) por região. Flags são P1 no máximo; mantenha onde os tenants vivem.

Dias 36–60: Tráfego, identidade e observabilidade que não vazam

• Roteamento: Subdomínios de região explícitos: eu.yourapp.com e us.yourapp.com. No login, resolva org → região no plano de controle e envie 302 para o subdomínio correto. Evite GeoIP. Torne determinístico e auditável.
• Auth/SSO: Tokens emitidos e verificados na região. Chaves (JWKS) hospedadas por região. O plano de controle pode federar identidade sem ver P0 se você só armazenar emissor com escopo de org e IDs de usuário opacos ao plano de controle.
• Logs/métricas/traces: Ingestão e armazenamento na região. Remova P0 na fonte. Para exportar a um SIEM global, pré‑hasheie e‑mails (com sal por região) e reduza paths/queries com P0. Configure testes de egress que quebrem builds se um novo campo de log contiver P0.
• Analytics: Rode um warehouse na região (BigQuery EU dataset, Snowflake EU ou ClickHouse EU) alimentado por jobs que removem PII. Exporte apenas P2 agregados com limiares de k‑anonymity (p. ex., suprimir coortes com n<10). Nada de exportar eventos brutos para endpoints globais.
• E‑mail/SMS: Use endpoints compatíveis com UE (SES eu‑west‑1, provedores na UE). Garanta que templates sejam renderizados na região e somente P2 saia (status de entrega). Atualize sua lista de subprocessadores.

Dias 61–90: Migração, DR e prova

• Adesão de tenants: Novos prospects da UE entram por padrão na região UE. Migrações para clientes UE existentes são em lotes: exporte dos EUA criptografado, importe na UE, faça o cutover de DNS/roteamento do app e então faça hard‑delete do P0 antigo após o aceite do cliente. Uma organização média (10–50 GB de P0/P1) pode ser movida em um final de semana de manutenção.
• DR e backups: Comprove sua postura declarada. Se estrita, rode exercícios trimestrais de backup/restore regionais na UE. Se balanceada, replique snapshots criptografados para uma segunda região na UE (não EUA) e teste que chaves nunca saem dos cofres da UE. Documente metas de RPO/RTO (p. ex., RPO≤15 min, RTO≤2 h).
• Acesso de suporte: Acesso JIT com aprovação. Tenants da UE acionam pools de suporte apenas UE por padrão. Ferramentas de gravação de sessão rodam na região; higienize P0. Todo acesso é logado no SIEM da UE. Break‑glass exige aprovação de VP e é reportado automaticamente ao cliente em até 24 horas.
• Verificação: Crie PII canário (p. ex., e‑mails como eu‑leak‑probe+GUID@yourapp.test) em staging e produção. Honeytokens alertam se aparecerem em qualquer sistema fora da UE. Adicione alertas de eBPF/VPC Flow Logs para egress inesperado a faixas de IP fora da UE a partir de VPCs da UE.

Custos e equipe: o que isso realmente exige

• Multiplicador de infra: Espere um aumento de 25–40% no gasto de infra para rodar uma segunda região com paridade (BD, storage de objetos, busca, filas, observabilidade). Você pode manter o plano de controle compartilhado global mínimo.
• Pessoas: 2–3 FTE‑mês de tempo de backend sênior para chegar aos primeiros tenants UE, mais 0,5 FTE contínuo de SRE/Plataforma para manter a paridade. Se você tem um time de plataforma forte, dá para comprimir o cronograma inicial.
• Desempenho: Tenants da UE verão melhorias de 100–200 ms de latência ponta a ponta vs. bater nos EUA. Seus clientes nos EUA não notarão a UE subindo se você isolar os caminhos corretamente.

Em troca, seu time de vendas pode parar de desviar de questionários sobre Schrems II e seus ciclos de compras vão encurtar. Na nossa experiência, residência destrava pilotos enterprise de 6–7 dígitos com payback de CAC em um ano.

Falhas comuns (e como evitá‑las)

• Cron jobs “globais”: Jobs batch que iteram todas as orgs vão cruzar regiões por acidente. Corrija particionando escalonadores por região e dirigindo batch por filas regionais.
• Redis compartilhado: Não aponte workers da UE para um Redis nos EUA porque “é só cache”. Caches vazam P0 e viram estado. Rode Redis/Valkey regionais e defina TTLs agressivos.
• Backdoors de admin: UIs internas de admin que leem entre regiões “por conveniência” são motores de descoberta para auditores. Faça admins escolherem o escopo de região explicitamente e imponha isso na camada de query.
• Logar tudo: Se seus logs contêm e‑mails brutos ou corpos de requisição, você não tem residência de dados — você tem vazamento de dados. Corrija a higiene de logging antes de escalar tráfego da UE.
• Proliferação de terceiros: O plugin de navegador do seu fornecedor de segurança, o uploader de screenshots da sua ferramenta de QA, o seu pixel de marketing — todos são subprocessadores. Faça inventário e cerque‑os.

Como falar sobre isso em avaliações de segurança

Auditores não querem poesia; querem arquitetura e evidências. Coloque isto em um apêndice de 2 páginas que você possa compartilhar sob NDA:

• Um diagrama: Plano de controle (global, sem P0) e dois planos de dados (UE, EUA) com setas mostrando apenas egress de P2.
• Uma tabela: Para cada sistema (BD, storage de objetos, busca, logs, analytics, e‑mail, suporte), liste a região, workloads e se P0/P1/P2 é processado ou armazenado.
• Uma política: P0/P1 nunca sai da região. Egress de P2 somente após transformações irreversíveis. Chaves são regionais e não exportáveis.
• Um teste: PII canário e monitoramento de egress rodando diariamente com alertas para security@.
• Um SLA: RPO/RTO por região e postura de DR (estrita ou balanceada) e a cadência dos exercícios de restauração.

Você realmente precisa disso agora?

Se qualquer uma destas for verdadeira, sim:

• Você perdeu ≥1 contrato enterprise nos últimos dois trimestres por causa de residência.
• ≥10% do seu pipeline contém prospects da UE que perguntaram onde os dados ficam.

Se nenhuma for verdadeira, construa os ganchos mesmo assim: adicione region_code às orgs, cerque P0 nos seus logs, pare de usar filas globais e separe as preocupações de plano de controle/dados. Essas mudanças te deixam melhor mesmo que você nunca abra Frankfurt.

Por que um pod nearshore ajuda

Este trabalho é transversal: schema de BD, sistemas de jobs, observabilidade, segurança e jurídico. Ele compete com os roadmaps de produto. Um pod nearshore focado — 6–8 horas de sobreposição com seu time core nos EUA — consegue executar o blueprint sem atrapalhar seus times de feature. Os rollouts mais rápidos que vimos unem um líder de plataforma nos EUA com uma equipe brasileira de backend/SRE entregando os clones regionais, a política de KMS e os testes de verificação em paralelo.

O que o movimento da Fastmail sinaliza

E‑mail é a classe de PII mais difícil — identidade, conteúdo e processamento contínuo. Se um provedor de e‑mail consegue oferecer uma região de dados na UE com limites limpos, sua ferramenta de workflow B2B, plataforma de analytics ou app de colaboração não tem desculpa. Clientes agora tratam residência como SSO: um checkbox que esperam ver. Você pode construir agora nos seus termos ou construir depois em pânico após perder um logo que você queria na sua homepage.

Principais lições

• Defina cedo o escopo de residência: armazenamento, processamento, acesso e dependências. Escreva isso.
• Adote tenancy fixado por organização e um plano de controle global com planos de dados regionais. Mantenha P0/P1 regionais, sempre.
• Use chaves KMS por região, BD/storage/busca/filas regionais e subdomínios explícitos por região para roteamento.
• Faça telemetria segura: remova P0 na região, exporte apenas agregados P2 com k‑anonymity.
• Escolha uma postura de DR que você consiga provar. Teste restores trimestralmente, documente RPO/RTO e mantenha chaves regionais.
• Orce um aumento de 25–40% em infra e 2–3 FTE‑mês para chegar aos primeiros tenants UE. O upside de vendas costuma pagar em um ano.
• Construa verificação: PII canário, monitores de egress e escopo de admin. Evidência vence promessas em auditorias.