← Voltar aos diagramas

CAP Theorem + ACID vs BASE

Teorema CAP, garantias transacionais e o espectro de consistência em sistemas distribuídos

🔒ConsistencyEvery read = latest write✅AvailabilityEvery request gets response🌐Partition ToleranceSurvives network splitsMANDATORYCP — Consistency + Partition Tolerance🗄️etcdRaft consensus🐘ZooKeeperZAB protocol📊HBaseStrong readsTrade-off: rejeita writes durante partitionAP — Availability + Partition Tolerance💎CassandraTunable CL⚡DynamoDBEventually consistent🛋️CouchDBMulti-masterTrade-off: pode retornar dados stale durante partitionACID (Transações Fortes)A: Atomicity — tudo ou nadaC: Consistency — invariantes mantidasI: Isolation — txn parecem seriaisD: Durability — persist após commitPostgreSQL, MySQLBASE (Pragmatic Trade-off)BA: Basically Available — sempre respondeS: Soft state — estado pode mudarE: Eventually consistent — converge (em ~ms a ~s, dependendo da latência)Cassandra, DynamoDBEspectro de Consistência →StrongSequentialCausalEventualWeak← mais latência, mais correto | mais rápido, menos garantias →Framework de DecisãoExemplos reais:Banking → CP + ACID (PostgreSQL) Dinheiro: sem eventual consistencySocial Feed → AP + BASE (Cassandra) Post demora 1s a aparecer: OKCart → AP, Checkout → CP Mesmo sistema, garantias diferentesPerguntas-chave: 1. Posso retornar dado stale? 2. Posso rejeitar writes? 3. Qual window de inconsistência? 4. Read:Write ratio? 5. Custo de inconsistência?

CAP Theorem: num sistema distribuído, só é possível garantir 2 de 3 propriedades simultaneamente

0/8