Compartilhar o banco de dados – o equívoco arquitetural mais difundido nas organizações

Fernando Paiva

Se dois sistemas lidam com um mesmo conjunto de dados, por que não compartilhar a mesma base? Afinal de contas, nada tão simples, óbvio e indolor, certo?

Para todo problema complexo há uma solução clara, simples e … errada – Henry Mencken

Infelizmente, talvez devido a obviedade dessa abordagem, ela seja tão utilizada no desenvolvimento de software corporativo.

Compartilhar uma base de dados, geralmente, implica no aumento do acoplamento, aumento no custo de manutenção, problemas de escalabilidade e gargalos de performance. É uma dívida técnica fácil de contrair e difícil de pagar

Veja também

Se é errado, por que os times insistem?

Há três respostas possíveis:

  1. Faltam cicatrizes! Não há experiência suficiente lidando com problemas causados pelo compartilhamento uma mesma base de dados entre diversas aplicações.
  2. Sobram traumas! Existem lembranças infelizes de estratégias de “segmentação” de bases de dados que não deram certo.
  3. Prazo artificialmente apertado!

De fato, não podemos ser alheios aos aspectos mercadológicos que envolvem o nosso trabalho. Time-to-market, metas e oportunidades de mercado, não são apenas importantes, são essenciais. Eventualmente, temos que assumir dívidas técnicas para atender essas necessidades do negócio e, na nossa visão, faz parte do trabalho de um profissional sênior entender quando “fazer errado”.

Todavia, se a rotina do nosso time é sempre ter que escolher “fazer o errado” e o momento de pagar as dívidas técnicas jamais chega, temos um sintoma sério de uma doença corporativa grave: No lugar de times de desenvolvimento, temos máquinas de produção de legado.

Mas, afinal, por que é errado?

Objetivamente, os principais problemas em compartilhar um bancos de dados entre aplicações são os seguintes:

  1. Problema de escalabilidade, visto que várias aplicações concentram carga de trabalho em um único banco de dados que se torna um gargalo de performance.
  2. Aumento do custo e tempo para se evoluir as aplicações devido ao alto acoplamento entre elas. Para mudar uma aplicação é preciso mudar várias.
  3. É quase impossível prever os impactos de uma alteração no banco de dados. Surgem problemas em produção devido a efeitos colaterais de alterações feitas em outros sistemas.
  4. Alterações no banco de dados demandaria testar, novamente, todas aplicações e eventualmente modificá-las, aumentando o custo do deploy
  5. Necessidade de alinhamento entre os times para gerenciar dependências entre os softwares pelo uso da mesma base.

Comum em todos esses pontos, muito mais grave do que o acoplamento entre aplicações é o acoplamento entre os times, que compromete o velocity.

Eventualmente, as aplicações passam a ser mantidas por times diferentes.  Não raro, equipes menos experientes fazem modificações indesejadas que impactam outros times.

O que seria o “certo”?

Se duas aplicações tem em seu core demandas por um mesmo conjunto de dados, talvez não devessem ser aplicações separadas. Entretanto, caso o cenário demande, realmente, aplicações distintas, devemos trabalhar com opções de integração menos “intrusivas”.

Há uma pluralidade de soluções de integração praticadas no mercado. A solução ideal varia conforme cada cenário.

Como substituir “acoplamento” por “integração”?

Sabendo que o compartilhamento, entre duas ou mais aplicações, de uma mesma base de dados reflete-se em problemas e que não há opção definitiva de fazer uma boa integração, devemos atentar para um processo que colabore com o pagamento dessa dívida (quando ela ocorrer).

Entendemos que o primeiro passo para “pagar a dívida” é entender, exatamente, a condição atual (AS-IS) da arquitetura. Ou seja, precisamos ter uma visão clara dos componentes envolvidos (incluindo o banco de dados que está sendo compartilhado), as responsabilidades de cada um desses componentes, a forma como se relacionam (incluindo integrações com sistemas externos), e a estratégia evolutiva.

O segundo passo seria entender qual seria o cenário ideal (TO-BE) de integração. Que novos componentes deveriam ser incluídos? Quais seriam as novas responsabilidades de cada componente? Como ocorreria o relacionamento entre os componentes?

É importante destacar que o cenário futuro pode ou não implicar na adoção de novos mecanismos tecnológicos. Em caso positivo é sempre importante verificar se as especificações de compliance da organização seriam respeitadas. Além disso, seria muito importante estabelecer o patrocínio executivo para a mudança.

Finalmente, o terceiro passo seria estabelecer um roadmap de entregas. Afinal, dependendo do tamanho do acoplamento, geralmente não é possível sair do AS-IS para o TO-BE em uma única empreitada.

Em resumo

O problema
Com intento de acelerar o desenvolvimento de integrações entre aplicações, é comum utilizar um único banco de dados. Porém, esta decisão implica em alto custo de manutenção, problemas de escalabilidade, gargalos de performance e a “emergência” de um legado.
O Insight
Há diversas alternativas, amplamente adotadas e documentadas, de integração que deveriam ser nossa preferência. Caso já tenhamos incorrido no erro de integrar aplicações compartilhando banco de dados, devemos recorrer a boas práticas de arquitetura de software para “pagar a dívida” assim que possível.
Os benefícios
Aplicações com baixo acoplamento autorizam times com baixo acoplamento. No fim, a saúde do software melhora e a capacidade dos times de entregar mais valor em menos prazo também.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
3 Comentários
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Maicon Wissmann
Maicon Wissmann
3 anos atrás

Estou trabalhando em uma migração de servidores de um software que tem todas essas más praticas aí de usar um banco de dados compartilhado(um dos bancos tem 1TB de dados)…
Não bastando isso os bancos(em torno de 32 bases) tem dependências entre si…
Essa divida técnica esta custando muito caro pra toda equipe agora…

Kevin Allen
Kevin Allen
3 anos atrás

Ótimo artigo, gostaria se possível, que falasse um pouco de técnicas que são utilizadas comumente em um cenário de acoplamento entre bancos. Ex: cenários em que o app precisa de um dado em “tempo real”.

Alessandro
Alessandro
3 anos atrás

Tenho usado menssageria para deixar os dados ‘mais perto’ de onde são necessários. Em um sistema baseado em DDD onde os ‘contextos delimitados’ são respeitados, o mesmo dado pode ter diferentes visões entre os contextos. Vou dar um exemplo bem banal mas que tem funcionado no meu caso: Tenho um contexto que é responsável pelos dados dos clientes. Ele é o dono da verdade nesse caso. Tem sempre os dados atuais dos clientes. Tenho outro serviço que precisa dos dados dos clientes, porém nem todos (alguns não precisam do endereço por exemplo). Então sempre que o serviço responsável pelo cliente inclui ou altera alguma informação ele dispara um evento para que todos os outros serviços que precisam de informações dos clientes possam pegar a parte necessária e gravar no seu banco local. Porém, neste cenário temos consistência eventual mas, em muitos casos, isso é aceitável. Agora se outro serviço precisar mesmo dos dados em tempo real, e não puder esperar nem alguns segundos para se atualizar, aí tem que haver comunicação síncrona mesmo entre os serviços (contextos), o que gera acoplamento, mas em casos específicos, pode ser a uma solução. O que eu não faço, de forma alguma, é acessar o banco de dados de outro serviço…. entre as 2 opções (apesar de ter outras) eu prefiro a comunicação síncrona mesmo. Mas, no projeto atual que estou trabalhando, em que os dados demoram poucos ou menos de 1 segundo pra se atualizar, ainda não precisei de comunicação síncrona entre nenhum contexto. Até porque, quando o front precisa dos dados atualizados dos ‘clientes’, seguindo o exemplo acima, ele pode fazer uma requisição diretamente no serviço de ‘clientes’.

AUTOR

Fernando Paiva
Larga experiência como CTO, especialista em execução tecnológica e estruturação de times ágeis de desenvolvimento de software.

NOVOS HORIZONTES PARA O SEU NEGÓCIO

Nosso time está preparado para superar junto com você grandes desafios tecnológicos.

Entre em contato e vamos juntos utilizar a tecnologia do jeito certo para gerar mais resultados.

Insights EximiaCo

Confira os conteúdos de negócios e tecnologia desenvolvidos pelos nossos consultores:

Engenharia de Software

Três vantagens reais de utilizar orquestradores BPM para serviços

Arquiteto de software e solução com larga experiência corporativa
Desenvolvimento de Software

Os principais desafios ao adotar testes

Especialista em Testes e Arquitetura de Software
Arquitetura de Dados

Insights de um DBA na análise de um plano de execução

Especialista em performance de Bancos de Dados de larga escala

Acesse nossos canais

Simplificamos, potencializamos e aceleramos resultados usando a tecnologia do jeito certo

EximiaCo 2022 – Todos os direitos reservados

3
0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

Compartilhar o banco de dados – o equívoco arquitetural mais difundido nas organizações

Para se candidatar nesta turma aberta, preencha o formulário a seguir:

Condição especial de pré-venda: R$ 14.000,00 - contratando a mentoria até até 31/01/2023 e R$ 15.000,00 - contratando a mentoria a partir de 01/02/2023, em até 12x com taxas.

Tenho interesse nessa capacitação

Para solicitar mais informações sobre essa capacitação para a sua empresa, preencha o formulário a seguir:

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse nessa solução

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse neste serviço

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

× Precisa de ajuda?