Tenho certeza que você viu isso chegando, "Depende".

Depende de tudo. E a solução para compartilhar dados do cliente para o departamento A pode ser completamente diferente para compartilhar dados do cliente com o departamento B.

Meu conceito favorito que surgiu ao longo dos anos é o conceito de "Consistência Eventual". O termo veio da Amazon falando sobre sistemas distribuídos.

A premissa é que, embora o estado dos dados em uma empresa distribuída possa não ser perfeitamente consistente agora, "eventualmente" será.

Por exemplo, quando um registro de cliente é atualizado no sistema A, os dados do cliente do sistema B agora estão desatualizados e não correspondem. Mas, "eventualmente", o registro de A será enviado para B através de algum processo. Então, eventualmente, as duas instâncias irão corresponder.

Quando você trabalha com um único sistema, você não tem "EC", em vez disso, você tem atualizações instantâneas, uma única "fonte de verdade" e, normalmente, um mecanismo de bloqueio para lidar com condições de corrida e conflitos.

Quanto mais suas operações puderem trabalhar com dados "EC", mais fácil será separar esses sistemas. Um exemplo simples é um Data Warehouse usado por vendas. Eles usam o DW para executar seus relatórios diários, mas não executam seus relatórios até o início da manhã e sempre analisam os dados de "ontem" (ou anteriores). Portanto, não há necessidade de tempo real para que o DW seja perfeitamente consistente com o sistema de operações diárias. É perfeitamente aceitável que um processo seja executado, digamos, no fechamento dos negócios e mova ao longo dos dias as transações e atividades em massa em uma única operação de atualização grande.

Você pode ver como esse requisito pode resolver muitos problemas. Não há contenção para os dados transacionais, não há preocupação de que alguns dados de relatórios sejam alterados no meio do acúmulo da estatística porque o relatório fez duas consultas separadas ao banco de dados ativo. Não há necessidade de que a conversa de alto detalhe sugue o processamento da rede e da CPU, etc. durante o dia.

Agora, esse é um exemplo extremo, simplificado e muito grosseiro de EC.

Mas considere um grande sistema como o Google. Como consumidor da Pesquisa, não temos ideia de quando ou quanto tempo leva para um resultado de pesquisa que o Google coleta até o nível de uma página de pesquisa. 1ms? 1s? 10s? 10 horas? É fácil imaginar como se você estiver acessando os servidores da Costa Oeste do Google, você pode muito bem obter um resultado de pesquisa diferente do que se você acessar os servidores da Costa Leste deles. Em nenhum momento essas duas instâncias são completamente consistentes. Mas, em grande medida, eles são principalmente consistentes. E para seu caso de uso, seus consumidores não são realmente afetados pelo atraso e atraso.

Considere o e-mail. A deseja enviar uma mensagem para B, mas no processo a mensagem é roteada pelos sistemas C, D e E. Cada sistema aceita a mensagem, assume total responsabilidade por ela e a entrega a outro. O remetente vê o e-mail seguir seu caminho. O receptor realmente não sente falta porque não sabe necessariamente que está chegando. Portanto, há uma grande janela de tempo que pode levar para que essa mensagem se mova pelo sistema sem que ninguém se preocupe em saber ou se importar com a rapidez com que ela é.

Por outro lado, A poderia estar no telefone com B. "Acabei de enviar, você já recebeu? Agora? Agora? Recebeu agora?"

Assim, há algum tipo de nível subjacente e implícito de desempenho e resposta. No final, "eventualmente", a caixa de saída de A corresponde à caixa de entrada de B.

Esses atrasos, a aceitação de dados obsoletos, sejam de um dia ou de 1 a 5 segundos, são o que controla o acoplamento final de seus sistemas. Quanto mais solto esse requisito, mais solto o acoplamento e mais flexibilidade você tem à sua disposição em termos de design.

Isso vale para os núcleos da sua CPU. Aplicativos modernos, com vários núcleos e vários segmentos executados no mesmo sistema, podem ter diferentes visualizações dos "mesmos" dados, apenas microssegundos desatualizados. Se o seu código pode funcionar corretamente com dados potencialmente inconsistentes entre si, então feliz dia, ele segue em frente. Caso contrário, você precisa prestar atenção especial para garantir que seus dados sejam completamente consistentes, usando técnicas como qualificações de memória volátil ou construções de bloqueio, etc. Tudo isso, à sua maneira, custo-desempenho.

Então, essa é a consideração básica. Todas as outras decisões começam aqui. Responder isso pode dizer como particionar aplicativos entre máquinas, quais recursos são compartilhados e como eles são compartilhados. Quais protocolos e técnicas estão disponíveis para mover os dados e quanto custará em termos de processamento para realizar a transferência. Replicação, balanceamento de carga, compartilhamento de dados, etc etc. Tudo baseado neste conceito.

Edite, em resposta ao primeiro comentário.

Correto, exatamente. O jogo aqui, por exemplo, se B não pode alterar os dados do cliente, então qual é o mal com os dados do cliente alterados? Você pode "arriscar" ficar desatualizado por um curto período de tempo? Talvez os dados de seus clientes cheguem devagar o suficiente para que você possa replicá-los de A para B imediatamente. Digamos que o troco seja colocado em uma fila que, por causa do baixo volume, seja coletado prontamente (<1s), mas mesmo assim estaria "fora de transação" com o troco original, e então há uma pequena janela onde A teria dados que B não.

Agora a mente realmente começa a girar. O que acontece durante esses 1s de "lag", qual é o pior cenário possível. E você pode projetar em torno dele? Se você puder projetar em torno de um atraso de 1s, você poderá projetar em torno de um atraso de 5s, 1m ou até mais. Quanto dos dados do cliente você realmente usa em B? Maybe B é um sistema projetado para facilitar a separação de pedidos do estoque. Difícil imaginar algo mais sendo necessário do que simplesmente um ID de cliente e talvez um nome. Apenas algo para identificar grosseiramente para quem é o pedido enquanto está sendo montado.

O sistema de separação não precisa necessariamente imprimir todas as informações do cliente até o final do processo de separação e, então, o pedido pode ter sido movido para outro sistema que talvez seja mais atual, especialmente com informações de remessa, então no final, o sistema de picking não precisa de quase nenhum dado do cliente. Na verdade, você pode INCORPORAR e desnormalizar as informações do cliente no pedido de separação, portanto, não há necessidade ou expectativa de sincronização posterior. Contanto que o ID do cliente esteja correto (que nunca mudará de qualquer maneira) e o nome (que muda tão raramente que não vale a pena discutir), essa é a única referência real que você precisa e todas as suas listas de seleção são perfeitamente precisas no momento da criação.

O truque é a mentalidade, de quebrar os sistemas e focar nos dados essenciais que são necessários para a tarefa. Os dados que você não precisa não precisam ser replicados ou sincronizados. As pessoas se irritam com coisas como desnormalização e redução de dados, especialmente quando são do mundo da modelagem de dados relacional. E com razão, deve ser considerado com cautela. Mas, uma vez distribuído, você desnormalizou implicitamente. Caramba, você está copiando no atacado agora. Então, você também pode ser mais esperto sobre isso.

Tudo isso pode ser mitigado por meio de procedimentos sólidos e compreensão completa do fluxo de trabalho. Identificar os riscos e elaborar políticas e procedimentos para lidar com eles.

Mas a parte difícil é quebrar a cadeia para o banco de dados central no início, e instruir as pessoas que eles não podem "ter tudo" como eles podem esperar quando você tem um único, central e perfeito armazenamento de informações.