Executando verificação de segurança...
Respondendo a "Meus 2 cents, Entendi a ideia, mas o buraco eh..." dentro da publicação Estratégia de rollback para reduzir danos em Produção
1
josefilho

Você trouxe bons pontos. E dada a proposta simplificada que usei pra apresentar a ideia, realmente, fica inviável aplicar em cenários reais.
Acredito que falhei em não adicionar a este contexto qual foi a inspiração, e olhando agora, acho que dava pra fazer uma implementação mais completa sem perder a simplicidade.

Mas a ideia da abstração foi "chupinhada" da abordagem de compensação de transações que o "Saga Pattern" implementa para ambientes distribuídos, aonde cada etapa da transação possui um mecanismo de compensação para que, em eventual falha na cadeia de um workflow distribuído, seja possível a reversão da transação.

Como ali, injetei o snapshot na camada de gestão de dados fica ainda mais complicado de associar com a ideia que mencionei acima.

Mas usando este comentário como oportunidade pra acrescentar um pouco mais ao texto, Eu diria que o ideal é que em camadas superiores, um workflow possa permitir tirar uma "fotografia" do estado atual das entidades relacionadas à operação, e ao gravar isso, possamos retroceder se necessário.
Isso faria da compensação, em linhas bem gerais, uma operação de atualização que reutiliza os dados anteriores à última edição.

Por exemplo, no caso do código que coloquei de exemplo, o correto seria mover a gestão do snapshot para a camada de negócios (casos de uso).

Bons estudos e um forte abraço!

Carregando publicação patrocinada...
1
Oletros

Meus 2 cents extendidos,

Refletindo mais um pouco - tem outro aspecto que tua publicacao traz a tona.

Antigamente, o usuario final tinha poucas possibilidades de alterar em lote grandes quantidades de dados de modo nao-supervisionado: para fazer este tipo de alteracao ou era atraves de alguma opcao do sistema (que tinha algum tipo de salvaguarda, como p.ex. permitir alteracoes em campos nao criticos) ou entao pedir para o TI fazer a alteracao (garantindo assim um minimo de analise da tarefa).

Quando a IA comeca a ter acesso a endpoints diretamente, e por consequencia, permitir ao usuario criar suas automacoes que podem afetar dezenas/milhares de dados em uma unica acao - talvez tenhamos de repensar metodologias de ACID/commit/transaction que tambem consideram este tipo de cenario.

Como foi comentado - snapshots poderiam ser um caminho, mas manter a integridade das regras de negocio em situacoes de rollback eh algo bem complicado: afinal, se um cliente recebeu uma notificacao de pedido aceito e faturamento realizado - como lidar com um rollback em algumas das entidades envolvidas ?

1
josefilho
  • Autor
    Autor

Perfeito. Bem colocado.
Para cenários aonde o impacto do rollback não envolve apenas entidades internas, de fato, não há uma resposta simples e talvez, a abordagem de compensação seja apenas a ponta de um iceberg, que certamente, permite muita exploração para melhorias futuras.
Acredito que esse tipo de padrão de compensação de transações vai se tornar cada vez mais comum, inclusive, a implantação de um 2 phase commit quando lidarmos com operações críticas.
Acredito muito que a discussão desse tipo de garantia de "consistência intencional" - com "intencional", estou tentando traduzir a ideia de que a consistência precisa estar atrelada à intenção de alterar o estado de uma entidade e mantê-la, na falta de uma expressão mais precisa - será cada vez mais frequente.
E falo isso com a propriedade de alguém que tem participado ativamente deste tipo de conversa, e enfrentado problemas desta natureza no dia-a-dia.

Um forte abraço!