Quiz

C — Nada com certeza; os retries precisam ser idempotentes.

Uma requisição perdida, um servidor que caiu, uma resposta perdida e um servidor muito lento parecem iguais para quem chama: silêncio. O timeout só diz "parei de esperar". Se a reserva de fato foi aplicada e a resposta se perdeu, um retry ingênuo reserva a unidade duas vezes. Tornar a operação idempotente (por exemplo, com um id único de requisição que o servidor usa para descartar duplicatas) torna o retry seguro.

D — 8.

No recebimento, a regra é max(local, received) + 1 = max(3, 7) + 1 = 8. Isso garante que o evento de recebimento tenha um timestamp maior do que o evento de envio, de modo que a relação "aconteceu-antes" sempre se reflete nos timestamps. Note que a recíproca não vale: um timestamp de Lamport menor não prova causalidade — para isso são necessários relógios vetoriais.

C — Partition Tolerance (tolerância a partições).

Partições de rede — em que as mensagens entre os nós são perdidas ou atrasadas — acontecem em qualquer sistema distribuído real, por falhas de hardware, congestionamento ou distância física. Como as partições não podem ser evitadas, a escolha prática de projeto é entre C (recusar requisições durante a partição) e A (continuar atendendo, possivelmente com dados desatualizados).

B — CP.

Ao recusar leituras durante uma partição, o sistema prioriza a consistência (nada de dados desatualizados) em detrimento da disponibilidade. Quando a partição se resolve, o serviço é retomado. ZooKeeper e etcd são exemplos clássicos de CP.

C — Apache Cassandra e DNS.

Ambos continuam atendendo requisições durante partições, aceitando que as respostas possam estar temporariamente desatualizadas (consistência eventual). ZooKeeper e etcd são CP; o PostgreSQL com replicação síncrona e o MongoDB com as escritas por maioria padrão se comportam como CP. Um Redis ou SQLite de um único nó nem sequer é replicado, então o CAP não se aplica de verdade a ele — ele fica no canto "CA" apenas porque não há um segundo nó do qual ficar particionado.

B — Mesmo sem partição: trade-off entre latência e consistência.

O CAP só descreve o comportamento durante uma partição. O PACELC acrescenta que, mesmo na operação normal, os sistemas precisam escolher entre latência menor (atender rápido, arriscando leituras levemente desatualizadas) e consistência mais forte (esperar o acordo da replicação antes de responder). O Cassandra é PA/EL; o MongoDB com escritas por maioria é PC/EC.

C — Armazenamento CP.

Em transações financeiras, a correção é inegociável. Um armazenamento CP se recusa a processar o pagamento durante a partição (o cliente recebe um erro, e não uma cobrança em dobro). Um armazenamento AP poderia processar o pagamento em dois nós simultaneamente antes de a partição se resolver, criando uma transação duplicada que não pode ser desfeita com segurança. O last-write-wins (D) descartaria silenciosamente uma das escritas conflitantes, e depende de relógios que derivam.

C — Uma única máquina ou uma rede local rigidamente controlada.

CA só funciona quando partições realmente não podem ocorrer — o que só é realista para um único servidor ou para uma rede local sob controle rigoroso. Em qualquer implantação conectada à internet ou geograficamente distribuída, P é, na prática, obrigatório, e a escolha real fica entre C e A.

D — PA/EL.

PA = durante uma partição (Partition), favorece a disponibilidade (Availability). EL = caso contrário (Else, operação normal), favorece a latência (Latency). O Apache Cassandra é o sistema PA/EL canônico — ele sempre responde rápido e aceita a consistência eventual nos dois cenários.

B — Não há garantia de término em um sistema assíncrono com ≥1 nó defeituoso.

O FLP (Fischer, Lynch, Paterson, 1985) prova esse limite fundamental: alguma ordenação azarada de atrasos pode manter qualquer algoritmo determinístico indeciso para sempre. Os algoritmos reais respondem a isso assumindo sincronia parcial (os atrasos acabam ficando limitados) ou usando aleatorização. Paxos e Raft nunca violam a safety e usam timeouts como substituto da detecção de falhas para progredir.

C — O timeout de eleição de um follower expira.

Cada follower mantém um timeout de eleição aleatório. Se nenhum heartbeat chega antes de ele expirar, o follower assume que o líder caiu e inicia uma nova eleição, incrementando o term e pedindo votos. Os timeouts aleatórios evitam que vários followers iniciem eleições ao mesmo tempo.

A — 1.

Uma escrita precisa de uma maioria: ⌊4/2⌋ + 1 = 3 nós. Com 2 nós fora do ar, restam apenas 2, o que não é maioria. Portanto, 4 nós toleram ⌊(4-1)/2⌋ = 1 falha — o mesmo que 3 nós, com uma máquina a mais que pode falhar. É por isso que clusters de consenso usam tamanhos ímpares (3 ou 5). Um cluster par ainda consegue eleger um líder (D é falsa); ele só não ganha nada com isso.

D — W + R > N.

Se o quórum de escrita W somado ao quórum de leitura R ultrapassa o total de réplicas N, pelo menos um nó que confirmou a escrita precisa participar de qualquer quórum de leitura. Essa sobreposição garante que a escrita mais recente esteja sempre visível em uma leitura por quórum, e é a base de sistemas como o Dynamo e da consistência ajustável do Cassandra (por exemplo, leituras e escritas QUORUM com N = 3: 2 + 2 > 3).

B — 7.

O merge do G-Counter toma o máximo elemento a elemento das posições: [max(4,2), max(1,3), max(0,0)] = [4, 3, 0], cuja soma é 7. Como cada nó só incrementa a sua própria posição, o máximo de uma posição é o seu valor mais recente; somar os dois totais (C) contaria em dobro, e o merge é comutativo e idempotente, então a ordem dos merges não importa (D é falsa).