Jim Gray, Processamento de Transações e Por Que o ACID Ainda Importa

Quem foi Jim Gray e por que suas ideias persistem

Jim Gray foi um cientista da computação obcecado por uma pergunta aparentemente simples: quando muitas pessoas usam um sistema ao mesmo tempo — e falhas são inevitáveis — como você mantém os resultados corretos?

Seu trabalho sobre processamento de transações ajudou a transformar bancos de dados de “às vezes corretos, se você tiver sorte” em infraestrutura sobre a qual dá para realmente construir um negócio. As ideias que ele popularizou — especialmente as propriedades ACID — aparecem em todo lugar, mesmo se você nunca usou a palavra "transação" em uma reunião de produto.

O que significa um “sistema confiável” (em termos simples)

Um sistema confiável é aquele em que os usuários podem contar com os resultados, não apenas com telas.

• Seu saldo bancário não fica negativo porque duas retiradas correram em paralelo.
• Um pedido é ou totalmente criado (com estoque reservado e pagamento registrado) ou não é criado — sem estados limbo misteriosos.
• Upgrades de assinatura não concedem (ou revogam) acesso aleatoriamente porque um job rodou duas vezes.
• Logs de auditoria e recibos batem com o que realmente aconteceu, mesmo após uma queda.

Em outras palavras: saldos corretos, pedidos corretos e nenhum registro faltando.

Onde você verá as ideias de Gray na vida real

Mesmo produtos modernos com filas, microsserviços e pagamentos de terceiros ainda dependem do pensamento transacional em momentos chave.

• Bancos: precisam de correção antes da velocidade quando dinheiro se move.
• Comércio: precisa de flows de checkout seguros sob carga: pedidos, estoque, pagamentos, reembolsos.
• SaaS: precisa de assinaturas, direitos e trilhas de auditoria consistentes para que clientes não sejam cobrados a mais ou fiquem sem acesso.

O que este artigo fará (e o que não fará)

Vamos manter os conceitos práticos: o que o ACID protege, onde os bugs costumam se esconder (isolamento e concorrência) e como logs e recuperação tornam as falhas sobrevivíveis.

Também cobriremos trade-offs modernos — onde você define limites ACID, quando transações distribuídas valem a pena e quando padrões como sagas, retries e idempotência dão uma consistência “boa o suficiente” sem overengineering.

Processamento de Transações em linguagem simples

Uma transação é uma forma de tratar uma ação de negócio em vários passos como uma única unidade “sim/não”. Se tudo dá certo, você confirma (commit). Se algo dá errado, você reverte como se nada tivesse acontecido.

Um exemplo simples: transferindo dinheiro

Imagine mover $50 da Conta Corrente para a Poupança. Isso não é uma única alteração; são pelo menos duas:

• Subtrair $50 da Conta Corrente
• Somar $50 na Poupança

Se seu sistema só faz “atualizações de um passo”, ele pode subtrair com sucesso e falhar antes da adição. Agora o cliente está sem $50 — e os tickets de suporte começam.

Checkout também é mais que um passo

Um checkout típico inclui criar o pedido, reservar estoque, autorizar o pagamento e registrar o recibo. Cada passo toca tabelas diferentes (ou até serviços diferentes). Sem pensamento transacional, você pode acabar com um pedido marcado como “pago” sem estoque reservado — ou estoque reservado para um pedido que nunca foi criado.

Onde as coisas falham na vida real

Falhas raramente acontecem em momentos convenientes. Pontos comuns de quebra incluem:

• O app cai após o passo 1, antes do passo 2.
• A rede cai entre seu app e o banco de dados.
• Um timeout ocorre, então o usuário clica em “Pagar” de novo.
• Um retry ou balanceador envia uma requisição duplicada.

O objetivo: todos os passos, ou nenhum

O processamento de transações existe para garantir uma promessa simples: ou todos os passos da ação de negócio entram em efeito juntos, ou nenhum entra. Essa promessa é a base da confiança — seja movendo dinheiro, fazendo um pedido ou mudando um plano de assinatura.

Atualização sobre ACID: o que cada letra protege

ACID é uma checklist de proteções que torna “uma transação” confiável. Não é termo de marketing; é um conjunto de promessas sobre o que acontece quando você altera dados importantes.

A — Atomicidade (tudo ou nada)

Atomicidade significa que uma transação ou completa totalmente ou não deixa vestígio.

Pense em uma transferência bancária: você debita $100 da Conta A e credita $100 na Conta B. Se o sistema cair após o débito e antes do crédito, atomicidade garante que toda a transferência seja revertida (ninguém “perde” dinheiro no meio do voo) ou que toda a transferência seja concluída. Não existe um estado válido onde só um lado aconteceu.

C — Consistência (as regras permanecem válidas)

Consistência significa que suas regras de dados (constraints e invariantes) se mantêm após cada transação confirmada.

Exemplos: um saldo não pode ficar negativo se seu produto não permite overdraft; a soma de débitos e créditos de uma transferência deve bater; o total de um pedido deve ser igual aos itens mais impostos. Consistência é em parte responsabilidade do banco de dados (constraints) e em parte da aplicação (regras de negócio).

I — Isolamento (concorrência não corrompe resultados)

Isolamento protege quando várias transações acontecem ao mesmo tempo.

Exemplo: dois clientes tentam comprar a última unidade de um item. Sem isolamento adequado, ambos podem ver estoque = 1 e ambos ter sucesso, deixando o estoque em -1 ou forçando correções manuais.

D — Durabilidade (o confirmado sobrevive)

Durabilidade significa que, uma vez que você vê “commit”, o resultado não vai desaparecer após uma falha ou queda de energia. Se o recibo diz que a transferência teve sucesso, o razão contábil deve continuar mostrando isso após o reboot.

Um mal-entendido comum

“ACID” não é um botão on/off. Sistemas e níveis de isolamento diferentes fornecem garantias diferentes, e frequentemente você escolhe quais proteções se aplicam a quais operações.

Bancos: correção vale mais que velocidade quando dinheiro se move

Quando se fala em “transações”, bancos são o exemplo mais claro: usuários esperam saldos corretos, sempre. Um app bancário pode ser um pouco lento; não pode estar errado. Um saldo incorreto pode gerar tarifas, pagamentos perdidos e uma trilha longa de trabalho manual.

Uma transferência, uma unidade de trabalho

Uma transferência simples é vários passos que devem dar certo ou falhar juntos:

• Debitar a conta A.
• Creditar a conta B.
• Escrever um registro de auditoria (quem/quando/porquê/quanto).

O pensamento ACID trata isso como uma única unidade. Se qualquer passo falhar — hiccup de rede, crash de serviço, erro de validação — o sistema não pode “ter sucesso parcial”. Caso contrário, você tem dinheiro faltando em A sem aparecer em B, dinheiro em B sem débito correspondente, ou sem trilha de auditoria para explicar o que aconteceu.

Por que “vamos consertar depois” fica caro

Em muitos produtos, uma pequena inconsistência pode ser corrigida na próxima release. No banco, “consertar depois” vira disputas, exposição regulatória e operação manual. Tickets de suporte disparam, engenheiros são puxados para incidentes e operações passam horas reconciliando registros divergentes.

Mesmo que você corrija os números, ainda precisa explicar o histórico.

Razões principais, logs imutáveis e reconciliação

Por isso os bancos dependem de razão contábil e registros append-only: em vez de sobrescrever história, registram uma sequência de débitos e créditos que somam. Logs imutáveis e trilhas de auditoria claras tornam a investigação e recuperação possíveis.

Reconciliação — comparar fontes independentes de verdade — atua como uma rede de segurança quando algo dá errado, ajudando equipes a identificar quando e onde ocorreu a divergência.

Impacto para o usuário

A correção compra confiança. Também reduz volume de suporte e acelera resolução: quando um problema ocorre, uma trilha limpa de auditoria e entradas consistentes permitem responder “o que aconteceu?” rapidamente e consertar sem adivinhação.

Comércio: pedidos, estoque e pagamentos sob carga

E‑commerce parece simples até você atingir tráfego de pico: o mesmo último item está em dez carrinhos, clientes atualizam a página e seu provedor de pagamentos dá timeout. É aqui que o mindset de processamento de transações de Jim Gray aparece em formas práticas e pouco glamourosas.

Um checkout, dividido em passos

Um checkout típico toca vários estados: reservar estoque, criar o pedido e capturar pagamento. Sob alta concorrência, cada passo pode estar correto isoladamente e ainda assim produzir um resultado ruim.

Se você decrementar estoque sem isolamento, dois checkouts podem ler “1 restante” e ambos ter sucesso — olá overselling. Se você capturar pagamento e depois falhar ao criar o pedido, cobrou o cliente sem ter o que entregar.

ACID ajuda mais na fronteira do banco de dados: envolva criação de pedido e reserva de estoque em uma única transação de banco de dados para que ambos confirmem ou revertam juntos. Você também pode forçar correção com constraints (por exemplo, "estoque não pode ficar abaixo de zero") para que o banco rejeite estados impossíveis mesmo quando o código da aplicação se comporta mal.

Pagamentos: por que “exatamente uma vez” é difícil

Redes perdem respostas, usuários dão duplo clique e jobs de background fazem retries. Por isso processar "exatamente uma vez" entre sistemas é difícil. O objetivo vira: no máximo uma vez para movimentação de dinheiro, e retries seguros em todo o resto.

Use chaves de idempotência com seu provedor de pagamento e grave um registro durável de “intenção de pagamento” atrelado ao pedido. Mesmo se seu serviço re-tentar, você não cobra em dobro.

Reembolsos e chargebacks

Devoluções, reembolsos parciais e chargebacks são fatos de negócio, não casos raros. Limites transacionais claros os tornam mais fáceis: você consegue ligar cada ajuste a um pedido, a um pagamento e a uma trilha de auditoria — assim a reconciliação fica explicável quando algo dá errado.

SaaS: assinaturas, direitos e trilhas de auditoria

SaaS vive de uma promessa: o que o cliente paga é o que ele pode usar, imediatamente e previsivelmente. Isso parece simples até misturar upgrades, downgrades, prorrata no meio do ciclo, reembolsos e eventos de pagamento assíncronos. Pensar no estilo ACID ajuda a manter a “verdade de cobrança” e a “verdade do produto” alinhadas.

Mudanças de assinatura sem surpresas

Uma mudança de plano costuma disparar uma cadeia de ações: criar/ajustar uma fatura, registrar prorrata, tentar cobrar, e atualizar direitos (features, assentos, limites). Trate isso como uma unidade de trabalho onde sucesso parcial é inaceitável.

Se uma fatura de upgrade é criada mas os direitos não são atualizados (ou vice‑versa), clientes perdem acesso que pagaram ou ganham acesso que não deveriam.

Um padrão prático é persistir a decisão de cobrança (novo plano, data efetiva, linhas de prorrata) e a decisão de direitos juntas, depois rodar processos downstream a partir desse registro confirmado. Se a confirmação do pagamento chegar depois, você pode avançar o estado com segurança sem reescrever história.

Correção em multitenant

Em sistemas multitenant, isolamento não é acadêmico: a atividade pesada de um cliente não deve bloquear ou corromper outro. Use chaves por tenant, limites transacionais claros por tenant e níveis de isolamento escolhidos com cuidado para que uma enxurrada de renovações do Tenant A não gere leituras inconsistentes para o Tenant B.

Trilhas de auditoria que respondem perguntas de suporte

Tickets de suporte geralmente começam com “Por que fui cobrado?” ou “Por que não consigo acessar X?”. Mantenha um log append-only de quem mudou o quê e quando (usuário, admin, automação), e ligue isso a faturas e transições de direitos.

Isso evita deriva silenciosa — onde faturas dizem “Pro” mas direitos ainda refletem “Basic” — e transforma reconciliação em uma query, não numa investigação.

Isolamento e Concorrência: onde a maioria dos bugs se esconde

Isolamento é o “I” do ACID, e é onde sistemas frequentemente falham de maneiras sutis e caras. A ideia central é simples: muitos usuários agem ao mesmo tempo, mas cada transação deve se comportar como se tivesse rodado sozinha.

Uma analogia do dia a dia: dois caixas, um item

Imagine uma loja com dois caixas e um último item na prateleira. Se ambos conferem o estoque ao mesmo tempo e veem “1 disponível”, podem cada um vendê‑lo. Nada “travou”, mas o resultado está errado — como um duplo gasto.

Bancos de dados enfrentam o mesmo problema quando duas transações leem e atualizam as mesmas linhas concorrentes.

Anomalias comuns que o isolamento evita

• Leituras sujas: ver mudanças de uma transação que ainda não confirmou (e que pode reverter).
• Atualizações perdidas: duas transações atualizam o mesmo registro e a escrita posterior sobrescreve silenciosamente a anterior.
• Bugs estilo duplo gasto: duas transações “reservam” o mesmo recurso escasso (estoque, saldo, assentos).

Níveis de isolamento em termos práticos

A maioria dos sistemas escolhe um nível de isolamento como trade‑off entre segurança e rendimento:

• Read committed: só lê dados confirmados. Evita leituras sujas, mas algumas anomalias ainda podem passar.
• Repeatable read: garante que se você reler a mesma linha, obtém o mesmo resultado. Reduz comportamento de "alvo em movimento", mas não evita todo tipo de conflito.
• Serializable: o mais forte — resultados são como se transações tivessem corrido uma a uma. Mais seguro, mas geralmente mais lento.

Escolha baseada no risco do negócio, não só no desempenho

Se um erro gera perda financeira, exposição legal ou inconsistência visível ao cliente, incline‑se para isolamento mais forte (ou bloqueio/constraints explícitos). Se o pior caso é um glitch temporário na UI, um nível fraco pode ser aceitável.

Isolamento mais alto reduz throughput porque o banco precisa de mais coordenação — esperar, bloquear ou abortar/retentar transações — para evitar interleavings inseguros. O custo é real, mas também é real o custo dos dados incorretos.

Logs, Durabilidade e Recuperação após Falhas

Quando um sistema cai, a pergunta mais importante não é “por que caiu?”, mas “em que estado devemos ficar após reiniciar?”. O trabalho de Jim Gray em processamento de transações tornou a resposta prática: durabilidade é alcançada por meio de logging disciplinado e recuperação.

O log de transações: a memória do sistema

Um log de transações (frequentemente chamado WAL) é um registro append-only de mudanças. É central para recuperação porque preserva a intenção e a ordem das atualizações mesmo se os arquivos de dados estavam a meio de uma escrita quando a energia caiu.

Durante o restart, o banco pode:

• Refazer mudanças confirmadas que não chegaram totalmente aos arquivos de dados.
• Desfazer transações incompletas para que atualizações pela metade não vazem ao estado final.

Por isso “confirmamos” pode continuar sendo verdade mesmo quando o servidor não desligou de forma limpa.

Write‑ahead logging (WAL) e por que habilita durabilidade

Write‑ahead logging significa: o log é forçado para armazenamento durável antes que as páginas de dados possam ser escritas. Na prática, o “commit” está ligado a garantir que os registros de log relevantes estão seguramente no disco (ou em algum outro armazenamento durável).

Se um crash acontece logo após o commit, a recuperação pode reproduzir o log e reconstruir o estado confirmado. Se o crash acontece antes do commit, o log ajuda a reverter.

Backups vs logs: você quer ambos

Um backup é uma cópia em um ponto no tempo. Logs são um histórico (o que mudou depois desse snapshot). Backups ajudam contra perda catastrófica (deploy ruim, tabela dropada, ransomware). Logs ajudam você a recuperar trabalhos confirmados recentes e suportam recuperação ponto‑a‑tempo: restaure o backup e então replique os logs até o momento escolhido.

Lembrete operacional: teste restaurações

Um backup que você nunca restaurou é uma esperança, não um plano. Agende exercícios regulares de restauração em um ambiente de staging, verifique checagens de integridade dos dados e cronometre quanto tempo a recuperação leva. Se não cumprir seus objetivos de RTO/RPO, ajuste retenção, envio de logs ou cadência de backups antes que um incidente force a lição.

Sistemas Distribuídos: limites ACID e alternativas práticas

ACID funciona melhor quando um banco de dados pode atuar como “fonte de verdade” para uma transação. O momento em que você espalha uma ação de negócio por múltiplos serviços (pagamentos, estoque, email, analytics) é quando você entra em território de sistemas distribuídos — onde falhas não parecem “sucesso” ou “erro” limpos.

Por que transações distribuídas são difíceis

Em um cenário distribuído, você deve assumir falhas parciais: um serviço pode confirmar enquanto outro cai, ou um hiccup de rede pode esconder o resultado verdadeiro. Pior, timeouts são ambíguos — a outra ponta falhou ou está apenas lenta?

Essa incerteza é onde nascem cobranças duplas, overselling e direitos faltantes.

Dois‑fases de commit (2PC) em termos simples

Two‑phase commit tenta fazer múltiplos bancos de dados confirmar “como um só”.

• Fase 1 (prepare): cada participante promete que pode confirmar e bloqueia o que precisa.
• Fase 2 (commit/abort): um coordenador diz a todos para finalizar ou para reverter.

Times frequentemente evitam 2PC porque pode ser lento, mantém locks por mais tempo (prejudicando throughput) e o coordenador vira gargalo. Também acopla fortemente os sistemas: todos participantes têm de falar o protocolo e ficar altamente disponíveis.

Alternativas práticas que escalam melhor

Uma abordagem comum é manter limites ACID pequenos e gerenciar trabalho entre serviços explicitamente:

• Sagas: dividir um grande processo em passos, cada um com sua transação local.
• Ações compensatórias: se o passo 4 falhar, rode passos de “desfazer” (reembolsar, liberar estoque).
• Outbox pattern: grave sua mudança no BD e o “evento a publicar” na mesma transação, depois envie de forma confiável.

Regra prática

Coloque as garantias mais fortes (ACID) dentro de um único banco de dados sempre que possível, e trate tudo que fica fora dessa fronteira como coordenação com retries, reconciliação e regras claras de “o que acontece se este passo falhar?”.

Retries, Idempotência e Requisições Duplicadas

Falhas raramente são “não aconteceu”. Mais frequentemente, uma requisição tem sucesso parcialmente, o cliente dá timeout e alguém (navegador, app móvel, job runner ou sistema parceiro) re-tenta.

Sem salvaguardas, retries criam o pior tipo de bug: código que parece correto e às vezes cobra em dobro, envia em dobro ou concede acesso em dobro.

O que idempotência significa (na prática)

Idempotência é a propriedade de que executar a mesma operação várias vezes tem o mesmo resultado final que executá‑la uma vez. Para sistemas voltados ao usuário, é “retries seguros sem efeitos duplos”.

Uma regra útil: GET é naturalmente idempotente; muitos POSTs não são, a menos que você os projete para isso.

Ferramentas que evitam duplicatas

Você normalmente combina alguns mecanismos:

• Chaves de idempotência: o cliente envia uma chave única por ação pretendida (ex.: Idempotency-Key: ...). O servidor grava o resultado indexado por esse valor e retorna o mesmo resultado nas repetições.
• Constraints únicas: impor “apenas um” no nível do banco (ex.: um pagamento por order_id, uma assinatura por account_id + plan_id).
• Tabelas de dedupe: armazenar IDs de requisição/evento processados (com TTL), comum para webhooks e filas.

Esses mecanismos funcionam melhor quando a checagem única e o efeito residem na mesma transação do banco.

Retries vs. transações e timeouts

Um timeout não significa que a transação reverteu; pode ter confirmado mas a resposta se perdeu. Por isso a lógica de retry deve assumir que o servidor pode ter tido sucesso.

Um padrão comum: gravar primeiro um registro de idempotência (ou bloqueá‑lo), executar efeitos colaterais e então marcar como completo — tudo dentro de uma transação quando possível. Se não couber tudo em uma transação (por exemplo, chamar gateway de pagamento), persista uma “intenção” durável e reconcile depois.

Exemplos do dia a dia

• Duplo clique em "Enviar pagamento": duas requisições idênticas chegam. Sem idempotência, você corre o risco de cobrar duas vezes.
• Reenvio de webhook: provedores reenviam eventos até serem confirmados. Sem dedupe, você pode criar faturas duplicadas ou provisionar acesso duas vezes.

Checklist de design e teste para dados confiáveis

Quando sistemas “parecem instáveis”, a causa raiz muitas vezes é pensamento transacional quebrado. Sintomas típicos incluem pedidos fantasmas sem pagamento correspondente, estoque negativo após checkouts concorrentes e totais divergentes onde razão, faturas e analytics não concordam.

Checklist de design (antes de codificar)

Comece escrevendo suas invariantes — fatos que devem ser sempre verdadeiros. Exemplos: “estoque nunca fica abaixo de zero”, “um pedido está ou não pago (não ambos)”, “cada mudança de saldo tem uma entrada correspondente no razão”.

Depois defina limites de transação ao redor da menor unidade que deve ser atômica para proteger essas invariantes. Se uma ação do usuário toca múltiplas linhas/tabelas, decida o que precisa confirmar junto e o que pode ser adiado com segurança.

Por fim, escolha como lidar com conflitos sob carga:

• Bloqueio vs. concorrência otimista (colunas de versão).
• Constraints únicas para prevenir duplicados (ex.: um pagamento por pedido).
• Regras claras de retry quando deadlocks/timeouts acontecerem.

Ideias de testes que pegam falhas reais

Bugs de concorrência raramente aparecem em testes de happy path. Adicione testes que criem pressão:

• Testes de concorrência: rode a mesma operação em muitas threads/processos; verifique invariantes após a conclusão.
• Injeção de falhas: mate o serviço no meio da transação, caia conexões com o BD ou force timeouts; verifique que a recuperação não deixa estados pela metade.
• Reproduza tráfego parecido com produção: reutilize sequências de requisição (sanitizadas) para reproduzir casos de borda e validar correções.

Sinais de monitoramento que valem alertar

Você não pode proteger o que não mede. Sinais úteis incluem deadlocks, tempo de espera por locks, taxas de rollback (especialmente picos após deploys) e diferenças de reconciliação entre tabelas fonte de verdade (razão vs. saldos, pedidos vs. pagamentos). Essas métricas frequentemente avisam semanas antes de clientes relatarem “dinheiro faltando” ou estoque negativo.

Como aplicar pensamento ACID sem overengineering

A contribuição duradoura de Jim Gray não foi só um conjunto de propriedades — foi um vocabulário compartilhado para “o que não deve dar errado”. Quando times conseguem nomear a garantia que precisam (atomicidade, consistência, isolamento, durabilidade), debates sobre correção deixam de ser vagos ("deveria ser confiável") e viram ações concretas ("esta atualização deve ser atômica com aquela cobrança").

Onde insistir em ACID

Use transações completas quando um usuário esperaria um resultado único e definitivo e erros são caros:

• Movimentação de dinheiro: cobranças, reembolsos, atualizações de saldo, pagamentos a terceiros.
• Confirmação de pedido: criar pedido + reservar estoque + registrar intenção de pagamento.
• Acesso e direitos: mudanças de assinatura, concessão de papéis, assentos de licença.
• Requisitos de auditoria: qualquer coisa que você precise explicar depois a cliente, finanças ou segurança.

Aqui, otimizar por throughput enfraquecendo garantias frequentemente só transfere custo para tickets de suporte, reconciliação manual e perda de confiança.

Onde garantias mais fracas são aceitáveis

Relaxe garantias quando inconsistência temporária for aceitável e fácil de curar:

• Modelos de leitura e analytics (relatórios alguns minutos atrasados geralmente são OK).
• Contadores não críticos (views, likes) onde duplicatas não importam.
• Efeitos assíncronos (emails, webhooks) desde que sejam idempotentes.

O truque é manter uma clara fronteira ACID ao redor da fonte de verdade e deixar o resto ficar defasado.

Próximos passos práticos (leves, alto impacto)

1. Liste seus fluxos críticos: dinheiro, pedidos, acesso e qualquer coisa que mude um contrato com o cliente.
2. Escreva invariantes em linguagem natural (e mantenha perto do código): "Um pedido é pago no máximo uma vez", "Um assento não pode ser atribuído duas vezes", "Saldo nunca fica negativo".
3. Mapeie cada invariante para um mecanismo: escopo de transação, constraints únicas, chaves de idempotência, log de auditoria append-only.
4. Teste os caminhos feios: retries, timeouts, duplo clique e falhas parciais.

Se você está prototipando esses fluxos (ou reconstituindo um pipeline legado), ajuda começar por uma stack que trate transações e constraints como primeiro‑classe. Por exemplo, Koder.ai pode gerar um front React mais um backend Go + PostgreSQL a partir de um chat simples, o que é uma forma prática de criar limites transacionais reais cedo (incluindo registros de idempotência, tabelas outbox e workflows seguros para rollback) antes de investir numa arquitetura completa de microsserviços.

Se quiser mais padrões e checklists, vincule essas expectativas a /blog. Se você oferece expectativas de confiabilidade por nível, deixe isso explícito em /pricing para que clientes saibam quais garantias de correção estão comprando.