La regione scelta determina dove Bird archivia ed elabora i dati della tua organizzazione. Influisce anche su quali regole di privacy transfrontaliera si applicano.
Dove risiedono i miei dati?
In una sola regione, scelta al momento della creazione dell'organizzazione.
A ogni organizzazione Bird viene assegnata una regione alla registrazione. us1 corrisponde agli Stati Uniti e eu1 all'Unione Europea, e la documentazione sulle regioni descrive cosa copre questa assegnazione:
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.
L'espressione da valutare è "never replicated". Un impegno di residenza che permettesse una copia altrove per ridondanza o analisi non sarebbe tale. Qui il piano dati è realmente separato per regione, ed è anche il motivo per cui la scelta è immutabile: spostare un'organizzazione tra regioni non è un'impostazione, è una migrazione che la versione attuale di API non offre.
Come viene applicata?
Nelle credenziali e nel routing, in modo che un errore fallisca in modo evidente.
Non esiste un singolo endpoint globale per il piano dati. Ogni regione ha il proprio host, e una chiave API indica la propria regione nel prefisso: una chiave bk_eu1_ appartiene a eu1. Gli SDK e la CLI leggono il prefisso e selezionano l'host senza bisogno di configurazione.
Quello che succede quando una richiesta arriva nel posto sbagliato è la 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
Rifiutare invece di inoltrare è la scelta progettuale che rende la residenza verificabile. Una piattaforma che facesse silenziosamente da proxy a una richiesta indirizzata male sarebbe comoda, ma significherebbe anche che una richiesta contenente dati personali avrebbe oltrepassato un confine prima che qualcuno se ne accorgesse. Qui non può succedere: la richiesta fallisce e l'errore indica l'host da usare.
Ogni risposta include anche un header X-Bird-Region che indica la regione che l'ha servita, così puoi verificare dove una chiamata è effettivamente atterrata invece di fidarti della configurazione.
Cosa non è vincolato alla regione?
Autenticazione e amministrazione dell'account, e la documentazione lo dichiara esplicitamente invece di lasciarlo implicito:
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.
Questo è un dettaglio da conoscere, non da sorvolare. L'accesso e la gestione dell'account coinvolgono dati di identità che devono funzionare da qualsiasi luogo, quindi queste due superfici sono globali per design, mentre tutto ciò che riguarda messaggi e destinatari non lo è. Se stai documentando i tuoi flussi di dati, questa distinzione è il confine da tracciare.
La residenza decide dove vanno i miei messaggi?
No, e confondere le due cose porta alla conclusione sbagliata in entrambe le direzioni.
La residenza riguarda dove vengono archiviati ed elaborati i tuoi dati. La consegna riguarda dove si trovano i tuoi destinatari, ed è governata da copertura, regole locali e sanzioni. Un'organizzazione eu1 può inviare a destinatari ovunque Bird consegni, e un'organizzazione us1 può inviare a destinatari europei. Paesi supportati e restrizioni copre il lato della consegna.
Ciò che la residenza decide è dove vive il record di quel messaggio in seguito: il messaggio stesso, i dati del destinatario, il log degli eventi. Quel record è di solito il vero oggetto di una domanda sulla protezione dei dati.
Cosa devo decidere in anticipo?
La regione, perché è l'unica parte che non puoi cambiare in seguito.
Poiché l'assegnazione è immutabile una volta confermata, la scelta della regione va inserita nel processo che crea la tua organizzazione di produzione, insieme a tutto ciò che si decide una sola volta. Un'organizzazione di test creata nella regione sbagliata è un piccolo fastidio; una di produzione è una migrazione.
Due aspetti correlati da definire contestualmente, dato che nelle revisioni vengono trattati insieme: il contratto per il trattamento dei dati che regola il rapporto, e dove il fornitore pubblica la propria lista di sub-responsabili, poiché un sub-responsabile in un'altra giurisdizione è una questione di trasferimento a cui la residenza da sola non risponde.
In breve
La residenza è una proprietà dell'organizzazione, non di una richiesta.
La regione viene assegnata alla registrazione, può essere modificata prima della conferma ed è immutabile in seguito nella versione attuale di API.
Nulla viene replicato tra le regioni.
Spazi di lavoro, chiavi, messaggi, dati dei destinatari e log degli eventi restano in una sola regione, ed è questo che rende significativo un impegno di residenza.
La chiave API contiene la propria regione, e un host sbagliato viene rifiutato.
Una richiesta che raggiunge la regione sbagliata riceve
421 Misdirected Requestcon l'indicazione dell'host corretto, invece di essere inoltrata silenziosamente.Due superfici sono globali per scelta.
Autenticazione e amministrazione dell'account si basano su dati replicati, ed è per questo che rispondono su un host indipendente dalla regione.