Fronteiras de mutação e side effects sem concentrar tudo num service Deus

O problema

Alguns backends acabam com um service que faz tudo:

• valida entrada
• decide regra
• grava estado
• chama API externa
• inválida cache
• publica evento
• manda e-mail
• atualiza métrica

No começo isso passa sensação de controle.

Depois vira um bloco difícil de:

• entender
• testar
• evoluir
• recuperar quando algo falha

Modelo mental

Vale separar duas coisas:

• mutação principal
• efeitos derivados

Mutação principal é o trecho que decide o novo estado autoritativo.

Efeito derivado é o que acontece por causa dessa decisão:

• notificação
• integração externa
• atualização de projeção
• analytics
• aquecimento de cache

Quando tudo mora no mesmo bloco sem fronteira, o sistema perde noção do que era essencial e do que era reação.

Exemplo simples

Imagine a aprovação de um saque.

Existe uma decisão central:

• aprovar ou negar
• registrar o novo status
• persistir o motivo

Depois disso podem existir efeitos:

• notificar o usuário
• pedir transferência ao provedor
• atualizar painel de risco
• publicar evento interno

Se tudo isso estiver colado no mesmo service, uma falha de e-mail ou provider pode bagunçar o fluxo principal inteiro.

O erro comum

O erro comum é reagir ao caos criando ainda mais centralização:

“vamos colocar tudo no PaymentService para ninguém se perder”

Isso quase sempre gera:

• service gigante
• efeito colateral escondido
• retry perigoso
• teste acoplado demais
• medo de mexer

O erro oposto também existe:

espalhar side effect em listener, helper e callback até ninguém mais conseguir explicar a ordem do fluxo.

Os dois extremos são ruins.

O que normalmente ajuda

Normalmente ajuda quando o time consegue responder com clareza:

• onde a mutação principal acontece?
• o que precisa ser consistente naquele momento?
• quais efeitos podem sair depois?
• quais efeitos pedem compensação, retry ou observação própria?

Na prática, costuma ficar melhor quando:

• o caso de uso explicita a mutação principal
• side effect relevante sai por mecanismo conhecido
• integração externa não fica escondida em utilitário
• falha derivada não reabre decisão já tomada sem critério

Como um senior pensa

Quem já precisou estabilizar fluxo quebrado costuma perguntar:

• este bloco está decidindo estado ou só reagindo?
• se eu reexecutar isso, estou repetindo mutação ou só tentando completar side effect?
• o sistema sabe diferenciar sucesso principal de reação incompleta?
• estou colocando tudo num service grande por clareza ou por falta de modelagem?

Essa separação melhora tanto o código quanto a operação.

Ângulo de entrevista

Esse tema aparece em backend, system design, modularização e incidentes.

O entrevistador quer ver se você entende:

• onde a decisão principal do fluxo mora
• como side effect deve ser tratado sem virar detalhe invisível
• por que service Deus parece simples e envelhece mal

Resposta forte costuma soar assim:

“Eu separaria a mutação principal dos efeitos derivados. A parte que decide e persiste o estado precisa ficar clara. O restante eu trataria como reação explícita, com mecanismo adequado de retry, observação e isolamento, em vez de concentrar tudo num service gigante.”

Takeaway direto

Backend saudável não esconde side effect.

Também não joga tudo em um service só para parecer organizado.