Estamos construindo uma plataforma web que incorpora vários serviços, cada um com seus próprios dados subjacentes. Esses serviços estão sendo construídos de forma independente, seguindo os princípios da Arquitetura Orientada a Serviços , mas são negociados com dados potencialmente relacionados. Estamos considerando se esses serviços devem compartilhar um grande banco de dados ou se cada um possui seu próprio banco de dados. (Planejamos usar o SQL Server 2008 Enterprise em um cluster do Windows 2008).

Algumas das vantagens de cada abordagem que já consideramos incluem:

Banco de dados único

• Relacionar dados de diferentes serviços pode ser vinculado por restrições de chave estrangeira
• Extratos analíticos são mais simples de escrever e mais rápidos de executar
• No caso de um desastre, é mais fácil restaurar a plataforma para um estado consistente
• Para dados referenciados por vários serviços, é provável que os dados armazenados em cache por um serviço sejam usados ​​logo depois por outro serviço
• A administração e o monitoramento são mais simples e baratos antecipadamente

Vários bancos de dados

• Trabalhos de manutenção, problemas de hardware, violações de segurança e outros fatores não afetam necessariamente toda a plataforma
• Supondo que cada banco de dados esteja em hardware separado, a expansão de várias máquinas gera mais benefícios de desempenho do que a expansão de uma grande

De uma perspectiva operacional, é mais vantajoso que cada serviço nesta plataforma obtenha seu próprio banco de dados ou que todos eles entrem no mesmo banco de dados? Quais fatores-chave informam uma resposta a esta pergunta?

Na minha opinião, o principal diferencial de sistemas SOA verdadeiros (sobre os pseudo SOA, sistemas mais avançados / distribuídos que estão se tornando onipresentes) é que não deve haver interação zero entre serviços discretos. Onde isso é alcançado, qualquer aplicativo que você compõe desses serviços pode e deve ser construído para tolerar a falha de qualquer parte consistente. Uma falha reduz a funcionalidade, mas o serviço é mantido.

Nesse cenário, é lógico ou necessário separar o banco de dados subjacente para cada serviço. Se, no entanto, você tiver serviços interdependentes, há pouco (talvez nada) a ser ganho com uma divisão.

Eu recomendo a leitura de sites como o HighScalability.com, que exploram as arquiteturas adotadas pelos sites do tipo nunca falham. Um dos meus favoritos ultimamente foi a história do Macaco do Caos da Netflix, mencionado em Coding Horror .

Abordando alguns dos pontos da sua pergunta:

No caso de um desastre, é mais fácil restaurar a plataforma para um estado consistente.

Isso é verdade, mas talvez você deva pensar em como desacoplar melhor esses serviços, para que isso deixe de ser um problema. Como alternativa, existem métodos para garantir a sincronização em vários bancos de dados, marcas de transação no SQL Server, por exemplo.

Para dados referenciados por vários serviços, é provável que os dados armazenados em cache por um serviço sejam usados ​​logo depois por outro serviço.

As soluções de cache distribuído (memcached et al) podem ajudar aqui, mas você estaria violando os princípios de independência de serviço. Isso seria comparável a ter dois serviços se comunicando diretamente, ou pior, ter um serviço acessando outro repositório de dados, ignorando completamente a interface de serviço. Inevitavelmente, os dados serão relacionados e serão entregues entre os serviços pela plataforma de chamada; as decisões complicadas tendem a ser em torno de qual serviço será o proprietário de quais dados. Os sites StackOverflow ou Programmers podem estar melhor posicionados para ajudar com os problemas mais gerais de SOA.

Supondo que cada banco de dados esteja em hardware separado, a expansão gera mais benefícios de desempenho.

Certamente, pode ser mais barato escalar em várias máquinas com especificações mais baixas do que escalar uma única máquina. Embora os custos mais baixos de hardware possam ser menores do que o custo total de propriedade, quando os custos menores de esforço adicional de desenvolvimento e complexidade operacional são considerados.

Se isso não é SOA e você apenas tem um caso em que os serviços componentes desta plataforma estão sendo construídos por diferentes equipes / fornecedores por razões logísticas, use um único banco de dados e ignore completamente tudo o que está acima! :)