Modelagem de dados para cargas de trabalho de nível de operadora

Os aplicativos empresariais implantados em uma única região normalmente podem ignorar esse modelo de design de aplicativo e delegar com segurança a responsabilidade para a camada de banco de dados para disponibilizar os dados de forma confiável. Esse comportamento não é o caso para aplicativos de nível de operadora, que devem ser implantados em várias regiões. A implantação de várias regiões força o arquiteto de aplicativos a considerar os compromissos que está disposto a aceitar para seus dados.

Teorema de CAP

Os bancos de dados podem fornecer três propriedades principais para os dados que gerenciam para um aplicativo, conhecido como CAP:

• Consistência: uma leitura de dados retorna a gravação mais recente.
• Disponibilidade: cada solicitação recebe uma resposta válida.
• Tolerância à partição: o sistema continua operando apesar do atraso ou da perda total de comunicação entre elementos.

O teorema CAP afirma que uma camada de banco de dados não pode fornecer todas essas três propriedades para os mesmos dados ao mesmo tempo na presença de partições de rede. O arquiteto precisa tomar decisões de design explícitas sobre quais das propriedades cap favorecer sob quais condições e como lidar com os casos de borda.

De acordo com o teorema CAP, qualquer banco de dados só pode garantir duas das três propriedades possíveis para os mesmos dados ao mesmo tempo na presença da partição de rede.

A implantação de várias regiões significa que a tolerância à partição se torna significativa. Na maioria dos casos, os arquitetos de nível de operadora priorizam a tolerância à partição e a disponibilidade em vez da consistência. Para cada tipo de dados, o arquiteto deve considerar quais compensações eles estão dispostos a fazer, considerando os casos de borda.

Por exemplo, considere o banco de dados de usuários do sistema. É aceitável que o banco de dados do usuário seja suspenso para somente leitura se houver uma partição de rede? Esse comportamento prioriza a consistência e a disponibilidade de leitura em vez da disponibilidade de gravação. Essa priorização poderá não ser adequada se for inaceitável que um usuário acesse um site isolado depois que suas permissões forem revogadas em outro lugar. O cenário descrito exigiria que todo o acesso ao banco de dados fosse bloqueado se houver uma partição, o que prioriza a disponibilidade de gravação em vez da disponibilidade de leitura.

Observação

Os comprometimentos feitos podem ser diferentes para bancos de dados diferentes dentro do mesmo aplicativo, já que os bancos de dados provavelmente terão perfis de uso diferentes.

Quando a consistência é o comprometimento, o aplicativo deve lidar com artefatos de inconsistência de dados usando CRDTs (tipos de dados replicados sem conflitos). O uso de CRDTs requer disciplina no design e na implementação do aplicativo. Seu uso significa que as mesclagens de dados após eventos de partição podem ser tratadas automaticamente pela camada de dados sem intervenção humana ou lógica complexa no nível do aplicativo.

Importante

Mais detalhes sobre as opções de plataforma de dados para sua carga de trabalho crítica estão disponíveis aqui

O arquiteto também deve entender as compensações no modelo de dados, que foram feitas dentro dos serviços dependentes. Essas compensações afetam o serviço entregue ao aplicativo porque essas compensações podem não estar alinhadas com os requisitos no nível do aplicativo.

Próxima etapa

Examine a área de design de modelagem de integridade para cargas de trabalho de nível de operadora.

Área de design: Modelagem de integridade