💻

Distributed Database Simulator

Visualize node replication, CAP theorem tradeoffs, and consistency propagation

💻 Experimente agora

\ud83e\udd14 What Is a Distributed Database?

A distributed database spreads data across multiple servers (nodes) in different locations. The CAP theorem says you can only guarantee two of three properties: Consistency (every read sees the latest write), Availability (every request gets a response), and Partition Tolerance (the system works despite network splits).

Why does this matter? Every major internet service from Google to Netflix relies on distributed databases. Understanding the tradeoffs between consistency and availability is essential for building reliable, scalable systems that serve billions of users.

📖 Aprofundamento

Analogia 1

Imagine um sistema de biblioteca com filiais em 5 cidades, todas compartilhando o mesmo catálogo. Quando alguém retira um livro na Filial A, todas as outras filiais precisam atualizar seus registros. Se a linha telefônica para a Filial C cair (uma partição de rede), a Filial C ainda poderá mostrar o livro como disponível — isso é um problema de consistência. Você pode bloquear todos os empréstimos até que a Filial C se reconecte (escolhendo a consistência) ou deixar que cada filial continue emprestando de forma independente e reconciliar mais tarde (escolhendo a disponibilidade).

Analogia 2

Pense em um bate-papo em grupo com amigos de diferentes países. Quando você envia uma mensagem, todos devem vê-la na mesma ordem. Mas se a Internet de alguém cair, ele perderá mensagens e poderá responder a informações desatualizadas, criando conversas conflitantes. Os bancos de dados distribuídos enfrentam exatamente esse problema em grande escala e usam técnicas como relógios vetoriais e CRDTs para resolver o caos quando todos se reconectam.

🎯 Dicas do simulador

Iniciante

Comece com 5 nós e fator de replicação 3 - isso significa que cada dado é armazenado em 3 dos 5 nós

Intermediário

Compare a consistência de gravação ALL vs ONE – ALL é mais lento, mas garante que cada réplica tenha os dados mais recentes

Especialista

Desative Vector Clocks e acione gravações simultâneas durante uma partição para observar conflitos não resolvidos

📚 Glossário

CAP Theorem
Teorema de Brewer afirmando que um sistema distribuído pode fornecer no máximo duas de três garantias: Consistência, Disponibilidade e Tolerância de Partição. Durante uma partição de rede, você deve escolher entre C e A.
Replication Factor
O número de cópias de cada dado mantido no cluster. Um fator de replicação de 3 significa que cada gravação é armazenada em 3 nós diferentes.
Quorum
A maioria das réplicas deve reconhecer uma leitura ou gravação para que a operação seja bem-sucedida. Para RF=3, o quorum é 2. As leituras de quorum combinadas com as gravações de quorum garantem consistência.
Consistency Level
Determina quantas réplicas devem responder antes que uma leitura ou gravação seja considerada bem-sucedida. ONE é mais rápido, mas pode retornar dados obsoletos; ALL é mais lento, mas sempre consistente.
Network Partition
Uma falha na comunicação da rede que divide o cluster em dois ou mais grupos de nós que não conseguem se comunicar entre si, forçando uma escolha entre consistência e disponibilidade.
Split-Brain
Uma condição perigosa em que uma partição de rede faz com que dois grupos de nós aceitem gravações conflitantes de forma independente, acreditando ser o cluster autoritativo.
Vector Clock
Uma estrutura de dados que rastreia a ordem causal de eventos em nós distribuídos. Cada nó mantém um contador lógico e a comparação dos relógios vetoriais revela se os eventos estão causalmente relacionados ou simultâneos.
CRDT
Tipo de dados replicados sem conflitos — uma estrutura de dados projetada para que atualizações simultâneas em diferentes réplicas sempre convirjam para o mesmo estado sem coordenação, usando propriedades matemáticas como comutatividade.
Last-Write-Wins (LWW)
Uma estratégia simples de resolução de conflitos onde a gravação com o carimbo de data/hora mais recente vence. Fácil de implementar, mas pode descartar silenciosamente atualizações simultâneas.
Gossip Protocol
Um padrão de comunicação ponto a ponto em que cada nó troca periodicamente informações de estado com um ponto aleatório, eventualmente propagando atualizações para todos os nós — inspirado na forma como os rumores se espalham.
Anti-Entropy
Um processo de reparo em segundo plano onde os nós comparam periodicamente seus dados com os pares e sincronizam as diferenças, garantindo consistência eventual mesmo após falhas.
Merkle Tree
Uma estrutura de dados de árvore hash usada para detectar com eficiência diferenças entre dados de réplica. Os nós comparam primeiro os hashes raiz e, em seguida, fazem uma busca detalhada para encontrar e reparar apenas as chaves específicas que diferem.
Tombstone
Um marcador indicando que os dados foram excluídos. As lápides devem ser retidas por um período TTL para evitar que os dados excluídos reapareçam quando um nó particionado com os dados antigos se juntar novamente ao cluster.
Eventual Consistency
Um modelo de consistência que garante que, se não forem feitas novas atualizações, todas as réplicas eventualmente convergirão para o mesmo valor. O atraso de propagação é o tempo até a convergência.
Write-Ahead Log (WAL)
Uma técnica de durabilidade em que as alterações são gravadas em um log sequencial antes de serem aplicadas ao banco de dados, permitindo a recuperação de falhas ao reproduzir o log.

🏆 Figuras-chave

Eric Brewer (2000)

Formulou o Teorema CAP na UC Berkeley, moldando fundamentalmente o design de banco de dados distribuído ao provar a impossibilidade de garantir simultaneamente consistência, disponibilidade e tolerância a partições

Leslie Lamport (1998)

Criou o algoritmo de consenso Paxos e foi pioneiro na teoria de sistemas distribuídos com conceitos como relógios lógicos, carimbos de data e hora de Lamport e o problema dos generais bizantinos

Diego Ongaro (2014)

Projetei o algoritmo de consenso Raft em Stanford, tornando o consenso distribuído compreensível e prático para sistemas do mundo real como etcd e CockroachDB

Werner Vogels (2007)

Liderei o design do Dynamo da Amazon, que introduziu hashing consistente, relógios vetoriais e quóruns desleixados — inspirando Cassandra, Riak e todo o movimento NoSQL

Jeff Dean & Wilson Hsieh (2012)

Co-projetado pelo Google Spanner, o primeiro banco de dados distribuído globalmente com transações consistentes externamente usando API TrueTime e sincronização GPS/relógio atômico

Marc Shapiro (2011)

Foi pioneiro em tipos de dados replicados livres de conflitos (CRDTs) no INRIA, fornecendo bases matemáticas para consistência eventual livre de coordenação

🎓 Recursos de aprendizagem

💬 Mensagem aos estudantes

Os bancos de dados distribuídos são a espinha dorsal da Internet moderna. Cada vez que você posta nas redes sociais, transmite um vídeo ou faz uma compra on-line, dezenas de nós de banco de dados distribuídos estão coordenados nos bastidores. O teorema CAP ensina-nos que a perfeição é impossível num mundo onde as redes falham – e que a engenharia consiste em fazer compensações inteligentes. Os conceitos que você explora aqui – replicação, consenso, resolução de conflitos – são os mesmos desafios que os engenheiros do Google, Amazon e Netflix resolvem todos os dias. A compreensão desses fundamentos lhe dará uma compreensão profunda de como o mundo digital realmente funciona e talvez o inspire a construir a próxima geração de sistemas de dados resilientes.

Começar

Grátis, sem cadastro

Começar →