{"id":24793149,"url":"https://github.com/diglopes/cap-theorem","last_synced_at":"2026-01-05T16:39:06.294Z","repository":{"id":272661033,"uuid":"913887572","full_name":"diglopes/cap-theorem","owner":"diglopes","description":null,"archived":false,"fork":false,"pushed_at":"2025-01-15T20:41:35.000Z","size":2,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-01-29T22:02:18.881Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/diglopes.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-01-08T14:45:16.000Z","updated_at":"2025-01-15T20:41:37.000Z","dependencies_parsed_at":"2025-01-15T22:48:46.360Z","dependency_job_id":"a69bfcd0-d50a-44be-8475-0d4fe20b34f6","html_url":"https://github.com/diglopes/cap-theorem","commit_stats":null,"previous_names":["diglopes/cap-theorem"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/diglopes%2Fcap-theorem","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/diglopes%2Fcap-theorem/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/diglopes%2Fcap-theorem/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/diglopes%2Fcap-theorem/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/diglopes","download_url":"https://codeload.github.com/diglopes/cap-theorem/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245315294,"owners_count":20595217,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-01-29T21:56:06.850Z","updated_at":"2026-01-05T16:39:01.255Z","avatar_url":"https://github.com/diglopes.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# O teorema de CAP\n\nO teorema de CAP, também conhecido como o teorema de Brewer, é um conceito fundamental em sistemas distribuídos. Ele afirma que um sistema distribuído não pode garantir simultaneamente todas as três seguintes propriedades:\n\n**Consistência (Consistency):** Todos os nós do sistema veem os mesmos dados ao mesmo tempo. Isso significa que uma leitura sempre retorna o valor mais recente após uma escrita bem-sucedida.\n\n**Disponibilidade (Availability):** Cada solicitação feita ao sistema recebe uma resposta, mesmo que algumas partes do sistema estejam indisponíveis. Ou seja, o sistema está sempre operacional.\n\n**Tolerância a Partições (Partition Tolerance):** O sistema continua a operar mesmo se houver falhas de comunicação ou \"partições\" na rede que impedem que os nós se comuniquem entre si.\n\n## Regras do teorema de CAP:\n\nDado que falhas de rede (partições) são inevitáveis em sistemas distribuídos reais, um sistema sempre terá que priorizar entre Consistência e Disponibilidade.\nÉ impossível atingir simultaneamente as três propriedades em um sistema que está sujeito a falhas de comunicação.\nExemplos de sistemas distribuídos:\n\n### CP (Consistência e Tolerância a Partições):\n\nSacrificam a disponibilidade. Quando ocorre uma partição, o sistema pode se tornar indisponível para manter a consistência.\n\n\u003e Exemplo: Bancos de dados como HBase, MongoDB configurado para consistência forte.\n\n### AP (Disponibilidade e Tolerância a Partições):\n\nSacrificam a consistência. Durante uma partição, os nós podem responder com dados desatualizados (inconsistentes).\n\n\u003e Exemplo: Sistemas como Cassandra, DynamoDB.\n\n### CA (Consistência e Disponibilidade):\n\nNão toleram partições. Esses sistemas dependem de redes confiáveis e falhas podem tornar o sistema completamente indisponível.\n\n\u003e Exemplo: Sistemas centralizados, como alguns bancos de dados relacionais.\n\n### Implicações práticas:\n\nNenhum sistema distribuído pode ter 100% de consistência, disponibilidade e tolerância a partições ao mesmo tempo. Os desenvolvedores precisam decidir qual propriedade priorizar com base nos requisitos do sistema. Por exemplo:\n- Um sistema financeiro pode priorizar consistência (CP).\n- Um sistema de redes sociais pode priorizar disponibilidade (AP).\n  \nEssa escolha é muitas vezes contextual e depende das necessidades específicas da aplicação e do ambiente onde ela opera.\n\n## Testes práticos\n\n### Cenário:\nConfigurar um cluster de um banco de dados distribuído, como o Cassandra (AP) ou o MongoDB (CP). Em seguida, simular partições de rede e observar o comportamento do sistema em termos de consistência, disponibilidade e tolerância a partições\n\n#### Passo 1: Instalar o Docker\nCertifique-se de que o Docker está instalado no seu ambiente. Guia oficial de instalação.\n\n#### Passo 2: Subir um cluster distribuído\nAqui, usaremos MongoDB como exemplo, configurado para replicação (um cluster com réplicas).\n\nCriar a rede Docker:\n```bash\ndocker network create cap-test\n```\n\nSubir três instâncias do MongoDB:\n```bash\ndocker run -d --name mongo1 --network cap-test mongo --replSet rs0\ndocker run -d --name mongo2 --network cap-test mongo --replSet rs0\ndocker run -d --name mongo3 --network cap-test mongo --replSet rs0\n```\n\nOu inicialize tudo pelo docker compose\n\n```bash\ndocker compose up\n```\n\n**Inicializar o cluster de réplicas:**\nConecte-se ao container mongo1 para configurar o cluster:\n\n```bash\ndocker exec -it mongo1 mongosh\n```\n\nNo shell do MongoDB:\n\n```javascript\nrs.initiate({\n  _id: \"rs0\",\n  members: [\n    { _id: 0, host: \"mongo1:27017\" },\n    { _id: 1, host: \"mongo2:27017\" },\n    { _id: 2, host: \"mongo3:27017\" }\n  ]\n});\n```\n\n#### Passo 3: Simular cenários CAP\n\n**1. Testar Consistência e Partição (CP):**\n- Simule uma partição de rede desconectando um dos nós:\n\n```bash\ndocker network disconnect cap-test mongo2\n```\n- Tente realizar leituras e escritas no cluster. Por padrão, o MongoDB prioriza consistência e pode se tornar indisponível para certas operações até resolver a partição\n\n**2. Testar Disponibilidade e Partição (AP):**\n- Configure o MongoDB para permitir operações de escrita mesmo em caso de partição. No **mongo1**, execute:\n\n```javascript\nrs.status().members.map(i =\u003e ({ name: i.name, health: i.health, state: i.stateStr }));\n```\n- Simule uma partição novamente:\n\n```bash\ndocker network disconnect cap-test mongo3\n```\n\n- Realize leituras e escritas. Você pode observar que algumas leituras podem retornar dados desatualizados.\n\n**3. Testar Consistência e Disponibilidade (CA):**\n- Sem simular partições, observe que o MongoDB mantém consistência e disponibilidade.\n\n\n#### Passo 4: Monitorar logs\n\nAcompanhe os logs dos containers para entender o comportamento durante as partições:\n\n```bash\ndocker logs -f mongo1\ndocker logs -f mongo2\ndocker logs -f mongo3\n```\n\n### Passo 5: Limpar o ambiente\n\nApós os testes, remova os containers e a rede:\n\n```bash\ndocker rm -f mongo1 mongo2 mongo3\ndocker network rm cap-test\n```\n\nou\n\n```bash\ndocker compose down\n```\n---\n\n## Conclusão\nEsse experimento ajuda a visualizar como sistemas distribuídos priorizam Consistência, Disponibilidade ou Tolerância a Partições em cenários reais. Com pequenos ajustes, você pode usar outros sistemas distribuídos, como Cassandra, Redis Cluster ou Etcd, para explorar diferentes comportamentos CAP.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdiglopes%2Fcap-theorem","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdiglopes%2Fcap-theorem","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdiglopes%2Fcap-theorem/lists"}