Eventualmente, consistência significa que as mudanças levam tempo para se propagar e os dados podem não estar no mesmo estado após cada ação, mesmo para ações ou transformações idênticas dos dados. Isso pode causar coisas muito ruins quando as pessoas não sabem o que estão fazendo ao interagir com esse sistema.
Não implemente armazenamentos de dados de documentos críticos para os negócios até entender bem esse conceito. Estragar a implementação de um repositório de dados de documentos é muito mais difícil de consertar do que um modelo relacional, porque as coisas fundamentais que serão estragadas simplesmente não podem ser consertadas, pois as coisas necessárias para consertá-las simplesmente não estão presentes no ecossistema. Refatorar os dados de um armazenamento de bordo também é muito mais difícil do que as simples transformações de ETL de um RDBMS.
Nem todos os armazenamentos de documentos são criados iguais. Hoje em dia (MongoDB) oferece suporte a transações de um tipo, mas a migração de datastores é provavelmente comparável à despesa de reimplementação.
AVISO: desenvolvedores e até arquitetos que não conhecem ou entendem a tecnologia de um repositório de dados de documentos e têm medo de admitir isso por medo de perder o emprego, mas foram treinados classicamente em RDBMS e que conhecem apenas sistemas ACID (quão diferente pode ser ?) e quem não conhece a tecnologia ou não dispõe de tempo para aprender, sentirá falta de projetar um armazenamento de dados de documentos. Eles também podem tentar usá-lo como um RDBMS ou para coisas como armazenamento em cache. Eles dividem o que deveriam ser transações atômicas que deveriam operar em um documento inteiro em partes "relacionais", esquecendo que replicação e latência são coisas, ou pior ainda, arrastando sistemas de terceiros para uma "transação". Eles farão isso para que seu RDBMS possa espelhar seu data lake, sem considerar se funcionará ou não e sem testes, porque eles sabem o que estão fazendo. Eles ficarão surpresos quando objetos complexos armazenados em documentos separados, como "pedidos", tiverem menos "itens do pedido" do que o esperado, ou talvez nenhum. Mas isso não vai acontecer com frequência, ou com frequência suficiente, para que eles simplesmente marchem para a frente. Eles podem até não acertar no problema do desenvolvimento. Então, em vez de redesenhar as coisas, eles lançam "atrasos" e "tentativas" e "fazem check-in" para falsificar um modelo de dados relacionais, o que não funcionará, mas acrescentará complexidade adicional sem nenhum benefício. Mas agora é tarde demais - a coisa foi implantada e agora os negócios estão sendo executados. Eventualmente, todo o sistema será descartado, o departamento será terceirizado e outra pessoa o manterá. Ainda não funcionará corretamente, mas eles podem falhar menos que a falha atual.
