Roteamento de solicitações na camada de computação

Com o roteamento de solicitações na camada de computação, o código executado na camada de computação determina se a solicitação deve ser processada localmente ou transmitida para uma cópia de si mesmo que está sendo executada em outra região. Quando você usa o modo de gravação em uma região, a camada de computação pode detectar que não é a região ativa e permitir operações de leitura locais enquanto encaminha todas as operações de gravação para outra região. Esse código da camada de computação deve estar ciente da topologia de dados e das regras de roteamento e aplicá-las de forma confiável, com base nas configurações mais recentes que especificam quais regiões estão ativas para quais dados. A pilha de software externa da região não precisa estar ciente de como as solicitações de leitura e gravação são roteadas pelo microsserviço. Em um design robusto, a região receptora valida se é a primária atual para a operação de gravação. Se não for, vai gerar um erro que indica que o estado global precisa ser corrigido. A região receptora também pode armazenar em buffer a operação de gravação por um tempo se a região primária estiver em processo de alteração. Em todos os casos, a pilha de computação em uma região grava somente em seu endpoint local do DynamoDB, mas as pilhas de computação podem se comunicar entre si.

O Vanguard Group usa um sistema chamado Global Orchestration and Status Tool (GOaST) e uma biblioteca chamada Global Multi-Region library (GMRlib) para esse processo de roteamento, conforme apresentado em re:Invent 2022. Eles usam um follow-the-sun único modelo primário. GOaSTmantém o estado global, semelhante ao controle de ARC roteamento discutido na seção anterior. Ele usa uma tabela global para rastrear qual região é a principal e quando a próxima troca primária está programada. Todas as operações de leitura e gravação são GMRlib concluídas, coordenadas comGOaST. GMRlibpermite que as operações de leitura sejam realizadas localmente, com baixa latência. Para operações de gravação, GMRlib verifica se a região local é a região principal atual. Nesse caso, a operação de gravação é concluída diretamente. Caso contrário, GMRlib encaminha a tarefa de gravação para a GMRlib região primária. Essa biblioteca receptora confirma que ela também se considera como região primária e gerará um erro se não for, o que indicará um atraso na propagação com o estado global. Essa abordagem oferece um benefício de validação ao não gravar diretamente em um endpoint remoto do DynamoDB.