Airbnb: evitando pagamento duplo (Orpheus)

01 · CONTEXTO

Pagamentos em uma arquitetura orientada a serviços

O Airbnb vinha migrando sua infraestrutura para uma arquitetura orientada a serviços (SOA). A fonte lista ganhos, como especialização dos desenvolvedores e iteração mais rápida, e aponta que, para cobrança e pagamentos, ficou mais difícil manter a integridade dos dados.

Uma chamada de API a um serviço que chama outros serviços a jusante, cada um mudando estado e possivelmente com efeitos colaterais, equivale a executar uma complexa transação distribuída.

1. Um cliente faz uma chamada de API a um serviço de pagamentos.

2. Esse serviço faz outras chamadas de API a serviços a jusante.

3. Cada serviço a jusante muda estado e pode ter efeitos colaterais.

4. O conjunto equivale a executar uma transação distribuída complexa.

02 · CONSISTÊNCIA

Consistência quando não há uma transação única

Para garantir consistência entre todos os serviços, a fonte menciona que protocolos como o commit em duas fases poderiam ser usados. Sem um protocolo desse tipo, as transações distribuídas dificultam manter a integridade dos dados, permitir degradação graciosa e alcançar consistência.

Além disso, requisições inevitavelmente falham em sistemas distribuídos: conexões caem e expiram em algum momento, sobretudo em transações que reúnem várias requisições de rede.

A fonte nomeia três técnicas comuns para alcançar consistência eventual: reparo na leitura, reparo na escrita e reparo assíncrono.

Notificações assíncronas do servidor ao cliente também são amplamente usadas na indústria de pagamentos para forçar a consistência no lado do cliente.

03 · A ESCOLHA

Reparo na escrita e idempotência

A solução descrita no post usa reparo na escrita: cada chamada de escrita do cliente ao servidor tenta reparar um estado inconsistente. A fonte observa que o reparo na escrita exige clientes mais inteligentes.

O subtítulo do artigo apresenta o resultado como um framework genérico de idempotência, construído para alcançar consistência eventual e correção na arquitetura de microsserviços de pagamentos.

Uma operação idempotente tem o mesmo efeito quando executada uma vez ou várias vezes.

1. Na estratégia de reparo na escrita, o cliente envia uma chamada de escrita ao servidor.

2. O serviço propaga a escrita a um serviço a jusante, que muda estado.

3. Conexões caem e expiram em algum momento, sobretudo em transações com várias requisições de rede.

4. Cada chamada de escrita do cliente ao servidor tenta reparar um estado inconsistente.

5. Verificações assíncronas rodadas pelo servidor funcionam como segunda linha de defesa.

04 · LIMITES DA FONTE

O que a parte pública cobre

A página marca o artigo como história exclusiva para membros, e o texto público se interrompe logo depois de afirmar que o reparo na escrita exige clientes mais inteligentes. Este caso se limita, portanto, ao problema e à estratégia de consistência apresentados nessa parte.