Onde colocar a regra: cliente, servidor ou banco

Toda equipe já teve essa reunião. Alguém diz "isso é regra de negócio, tem que ficar no backend". Alguém responde "no front é mais rápido de mudar". Alguém, do fundo da sala, sentencia: "o banco que garanta". E a reunião termina sem decisão, com um documento aberto que ninguém vai escrever.

O problema é que a pergunta está mal formulada. "Onde colocar a regra" parece uma questão de gosto ou de dogma. Não é. É uma questão de superfície de escrita.

A pergunta que resolve a discussão

Quantos caminhos existem para escrever esse dado?

Se existe um só caminho — uma única API, um único serviço, e todo mundo passa por lá — a regra pode viver onde for mais conveniente para o time. Nas primeiras semanas de qualquer produto, quase sempre é no servidor.

Se existem dois ou mais caminhos, a conta muda. E quase todo sistema real tem mais de um: a API, o painel administrativo, o importador de CSV que o time comercial usa, a carga em lote noturna, o script que o estagiário rodou "só uma vez", a função de migração, o seed de teste.

Toda regra que mora só no servidor é contornada por todos os caminhos que não passam pelo servidor.

Três lugares, três contratos diferentes

Nenhum dos três é o "certo". Cada um tem um contrato, e confundir os contratos é o que dá dor de cabeça.

Onde	Contrato	Para que serve	Quando falha
Cliente	UX	avisar rápido, evitar digitação inútil, guiar o preenchimento	nunca é fonte da verdade: é sugestão
Servidor	Domínio	aplicar regra de negócio que muda com o mercado	pode ser contornado por quem não passa por ele
Banco	Invariante	garantir que o dado não existe em estado impossível	é o mais caro de alterar

A distinção que importa é entre regra que muda e invariante que não pode ser violada.

• "Pedido acima de R$ 500 precisa de aprovação de um gerente": regra de negócio. Muda em janeiro, muda de novo em março. Pertence ao servidor.
• "Saldo não pode ficar negativo": invariante. Nunca foi diferente e nunca vai ser. Pertence ao banco.

Colocar regra que muda no banco é caro: alterar schema em produção tem cerimônia, janela e medo. Colocar invariante só no servidor é frágil: basta um caminho de escrita esquecido para o dado ficar corrompido — e corrupção silenciosa é o tipo que aparece três meses depois na conciliação.

O invariante como última linha de defesa

O banco não precisa saber por que o saldo não pode ser negativo. Ele só precisa garantir que não seja. Em Postgres, isso custa uma linha:

ALTER TABLE contas
  ADD CONSTRAINT saldo_nao_negativo CHECK (saldo >= 0);

E se o débito precisa ser atômico, a garantia vem junto:

UPDATE contas
   SET saldo = saldo - $1
 WHERE id = $2
   AND saldo >= $1
RETURNING saldo;

UPDATE ... WHERE saldo >= $1 RETURNING resolve em uma instrução o que muita gente faz em três (ler, comparar, escrever) — e por isso mesmo sobrevive a duas requisições simultâneas, que é onde a versão em três etapas morre.

Se a operação retornar zero linhas, a regra foi violada. O código trata como erro de negócio; o banco nunca chegou a ficar inconsistente.

O erro clássico: três implementações que discordam

O outro extremo é validar em todo lugar e manter as três cópias sincronizadas na base da disciplina. Começa assim:

1. cliente: aceita CPF com 11 dígitos;
2. servidor: aceita CPF com 11 dígitos e valida o dígito verificador;
3. banco: aceita qualquer texto de até 14 caracteres.

Seis meses depois, o cliente permite 14 caracteres porque alguém "melhorou" o formulário para aceitar máscara, o servidor continua validando 11, e o banco virou o único lugar onde o dado entra torto — pela importação. Ninguém errou de propósito: as três cópias simplesmente seguiram vidas diferentes.

A regra prática que evita isso: cada verificação existe uma única vez na forma mais forte que o caminho exige. O servidor tem a validação completa; o banco tem só o invariante que não pode ser violado de jeito nenhum; o cliente tem só o suficiente para não incomodar o usuário.

Checklist de três linhas

Antes de decidir onde a regra mora, responda:

1. Existe mais de um caminho de escrita? Se sim, a garantia precisa estar no ponto por onde todos passam — normalmente o banco.
2. Essa regra muda com o negócio ou é uma verdade permanente? Muda: servidor. Permanente: banco.
3. Se essa regra falhar por um dia inteiro, alguém perde dinheiro ou dado real? Se sim, o banco entra na história, sem discussão.

Se as três respostas apontarem para lugares diferentes, você acabou de descobrir por que as três cópias existem — e por que duas delas vão divergir.