Sagas Transacionais - Arquitetura de Software: As Partes Difíceis

1. Anotações

O conceito de saga é anterior aos microsserviços.
Ele foi cunhado em 1987 para lidar com locks de banco de dados nas primeiras arquiteturas distribuídas.
Uma saga, para Chris Richardson, é uma sequência de transações locais onde cada atualização publicação um evento, disparando, assim, a próxima atualização na sequência. Se alguma dessas atualizações falhar, a saga emite uma série de atualizações compensatórias para desfazer as alterações anteriores feitas durante a saga.
Uma saga pode ser definida sob três características:
- comunicação - síncrona ou assíncrona
- consistência - atômica ou eventual
- coordenação - orquestrada ou coreografada
Padrão: Epic Saga
- comunicação síncrona, consistência atômica e coordenação orquestrada (sao)
- é conhecida também como Saga Orquestrada
- o objetivo é imitar o comportamento de sistemas monolíticos
- é mais familiar aos arquitetos e desenvolvedores de sistemas transacionais tradicionais
- um serviço orquestrador orquestra um fluxo de trabalho que inclui atualizações para n serviços que devem ocorrer transacionalmente, isto é, ou todas as n chamadas são bem sucedidas ou nenhuma
- não existe uma solução limpa para transações distribuídas, elas possuem uma série de desafios
- uma atualização de compensação é aquela que reverte uma ação de gravação de dados executada por outro serviço como, por exemplo, (1) reverter uma atualização, (2) reinserir linha excluída ou (3) excluir linha inserida
- um padrão de transação de compensação atribui um serviço para monitorar a integridade transacional de uma solicitação
- em uma estrutura de transação de compensação, o mediador monitora o sucesso das chamadas e emite chamadas de compensação para outros serviços se uma ou mais solicitações falharem
- as falhas podem ser operacionais ou de domínio
- é um padrão amplamente utilizado, modela o comportamento familiar e tem um nome de padrão bem estabelecido
- a vantagem é a coordenação transacional que imita sistemas monolíticos orquestrador como proprietário do fluxo de trabalho
- características
  - acoplamento
    - muito alto, em todas as dimensões possíveis pois modela o comportamento acoplado de um monolito mas com os problemas de arquiteturas distribuídas
  - complexidade
    - nas condições de erros e nas operações de desfazer
    - a sicronicidade ajuda a lidar com condição de corrida
  - responsividade/disponibilidade
    - a orquestração cria gargalo e as chamadas assíncronas também impactam no desempenho e capacidade de resposta
  - escala/elasticidade
    - similar à responsividade
Padrão: Phone Tag Saga
- comunicação síncrona, consistência atômica e coordenação coreografada (sac)
- faz referência a brincadeira infantil chamada telefone sem fio
- o arquiteto não designa nenhum orquestrador formal mas, por causa da atomicidade, é necessário algum grau de coordenação
- o serviço inicial pode ser o front controller e tornar-se o ponto de coordenação
- se houver um erro, cada serviço deve ter uma lógica integrada para enviar solicitações de compensação de volta ao longo da cadeia
- o front controller pode-se tornar tão complexo quanto um mediador
- é recomendado para fluxos de trabalhos simples
- características
  - acoplamento
    - menos acoplamento e complexidade do fluxo de trabalho distribuído entre os serviços
  - complexidade
    - mais complexo pois quanto maior o fluxo de trabalho mas lógica deve ter em cada serviço para compensar a falta de orquestrador
  - responsividade/disponibilidade
    - melhor responsividade
  - escala/elasticidade
    - aumento ligeiro da escalabilidade
Padrão: Fairly Tale Saga
- comunicação síncrona, consistência eventual e coordenação orquestrada (seo)
- refere-se às histórias felizes com enredos fáceis de seguir
- se um serviço estiver inativo temporariamente, a consistência eventual permite armazenar em cache uma alteração até que o serviço seja restaurado
- o orquestrador coordena solicitação, resposta e tratamento de erros (não gerencia as transações)
- o serviço mantém a responsabilidade de gerenciar transações
- aparece comumente nas arquiteturas de microsserviços
- a consistência eventual remove o desafio de coordenação mais difícil, especialmente para tratamento de erros
- não possui transação holística
- cada serviço de domínio gerencia seu próprio comportamento transacional, contando com consistência eventual para o fluxo de trabalho geral
- características
  - acoplamento
    - alto acoplamento mas livre da transacionalidade
  - complexidade
    - baixa, inclui as opções mais convenientes
  - responsividade/disponibilidade
    - geralmente boa, mas com assincronismo é melhor
  - escala/elasticidade
    - a falta de acoplamento leva a uma escala maior
Padrão: Time Travel Saga
- comunicação síncrona, consistência eventual e coordenação coreografada (sec)
- evita mediador central e coloca responsabilidade nos serviços participantes
- cada serviço aceita uma solicitação, executa uma ação e encaminha para outro serviço
- pode implementar padrão de projeto chain of responsabiliy ou padrão arquitetural pipes and filters
- cada serviço tem a sua própria transacionalidade
- mais adequado para fluxos de trabalho simples
- padrão funciona bem para fluxos de trabalho no estilo "fire and forget"
- a falta de acoplamento aumenta a escalabilidade do padrão
- características
  - acoplamento
    - baixo pela ausência de orquestrador e consistência eventual
  - complexidade
    - baixa, pela falta de transicionabilidade
  - responsividade/disponibilidade
    - média, pois cada serviço deve lidar para restaurar a consistência eventual e isso causa sobrecarga de chamadas síncronas
  - escala/elasticidade
    - alta
Padrão: Fantasy Fiction Travel Saga
- comunicação assíncrona, consistência atômica e coordenação orquestrada (aao)
- difere da Epic Saga pela comunicação assíncrona
- a assincronia traz desempenho mas adiciona complexidade em relação coordenação
- perda da sincronicidade
  - as respostas podem vir fora de ordem
  - cria o estado transacional assíncrono (possui resultados pendentes)
- perda da suposição serial
  - o serviço B pode terminar antes do serviço A
  - pode haver respostas duplicadas ou fora de ordem
  - não pode seguir sequência fixa
- novos problemas
  - surgem problemas clássicos de concorrência e paralelismo
  - deadlocks ou impasses - duas operações ficam esperando uma à outra e nenhuma avança
  - race conditions ou condições de corrida - quando a ordem afeta o resultado como estoque decrementado duas vezes
  - outros problemas como coordenação de mensagens, garantia de idempotência, ordenação, retries, backpressure
- características
  - acoplamento
    - alto, deve-se lidar com condições de corrida
  - complexidade
    - alto, fluxo de trabalho complexo e operação e depuração complexa ao lidar com esses fluxos de trabalhos
  - responsividade/disponibilidade
    - baixa
  - escala/elasticidade
    - baixa
- padrão mais popular do que deveria ser na tentativa equivocada de melhorar o desempenho do Epic Saga
Padrão: Horror Story Saga
- comunicação assíncrona, consistência atômica e coordenação coreografada (aac)
- é a pior combinação possível
- é um antipadrão
- a combinação é horrível por combinar acoplamento rígido da consistência atômica com acoplamentos flexíveis da comunicação assíncrona e coordenação coreografado
- não existe nenhum mediador para gerenciar a consistência transacional em um ambiente assíncrona
- a multiplicidade e a complexidade das condições de erro a tornam inviável
- é melhor escolher o padrão Anthology Saga que remove a transacionalidade holística
- características
  - acoplamento
    - não é o pior, perde para o Epic Saga
  - complexidade
    - altíssima, requer transacionalidade combinado com assincronicidade e coreografia
  - responsividade/disponibilidade
    - baixa, exige transação holística
  - escala/elasticidade
    - média, melhor do que aqueles com mediador
- pode ser resultado de um arquiteto bem-intencionado começando com um padrão Epic Saga que quer manter a transacionalidade, mas incluir comunicação assíncrona e coordenação coreografada para melhor desempenho
Padrão: Parallel Saga
- comunicação assíncrona, consistência eventual e coordenação orquestrada (aeo)
- é o padrão Epic Saga com os objetivos mais difíceis facilitados (transação e comunicação síncrona)
- usa mediador tornando-o adequado para fluxos de trabalho complexos
- usa comunicação assíncrona permitindo execuçõa paralela e melhor capacidade de resposta
- o serviço de domínio é responsável pela consistência e pode exigir alguma sincronização de dados compartilhados (em segundo plano ou via mediador)
- a falta de transacionalidade impõe mais carga ao mediador para resolver erros e outros problemas de fluxo de trabalho
- características
  - acoplamento
    - baixo nível de acoplamento, transação no nível do serviço e assincronicidade permite processamento paralelo
  - complexidade
    - baixa (devido ao baixo acoplamento) e orquestração permite fluxos de trabalhos mais simples
  - responsividade/disponibilidade
    - alta, por causa da falta de transações e da comunicação assíncrona e capacidade de escalar serviços individualmente
  - escala/elasticidade
    - alta, por causa da comunicação assíncrona e a capacidade de escala por serviço
- pode ser usado em cenários de fluxo de trabalho complexos e que precisam de alta escala
Padrão: Anthology Saga
- comunicação assíncrona, consistência eventual e coordenação coreografada (aec)
- possui características completamente opostas ao do padrão Epic Saga
- é o padrão com menor acoplamento
- usa fila de mensagens para comunicação assíncrona entre serviços sem orquestração
- cada serviço de domínio mantém a sua própria integridade transacional
- cada serviço de domínio deve incluir mais contexto (tratamento de errose outras estratégias de coordenação) sobre os fluxos de trabalho dos quais participam
- a falta de orquestração torna os serviços mais complexos, mas permite rendimento, escalabilidade e elasticidade
- não funciona bem para fluxos de trabalho complexos, especialmente na resolução de erros de consistência
- funciona para fluxos de trabalho simples e principalmente lineadres nos quais os arquitetos desejam alto rendimento
- o grau de desacoplamento dificulta a coordenação de fluxos de trabalhos complexos ou críticos
- características
  - acoplamento
    - muito baixo, focado em alto rendimento, escalabilidade e elasticidade
  - complexidade
    - alta, principalmente para fluxos de trabalho complexos que pedem um orquestrador
  - escala/elasticidade
    - alta, por falta geral de acoplamento
  - responsividade/disponibilidade
    - alta, devido a falta de reguladores de velocidade
- é adequado para comunicação com alta taxa de transferência e com condições de erros simples ou pouco frequentes
- pode usar o padrão arquitetural pipes and filters

2. Palavras-Chaves

serviços distribuídos
fluxo de trabalho
transacionalidade
interação entre serviços
transação de compensação
integridade transacional
front controller
idempotência
condições de corrida
acoplamento de selo ou stamp coupling
transação holística

marcelgsantos/sagas-transacionais.md

Sagas Transacionais - Arquitetura de Software: As Partes Difíceis

1. Anotações

2. Palavras-Chaves

3. Referências