Um fluxo de pedido passa por pagamentos, estoque e envio, cada um com o próprio banco de dados. Como você mantém a coisa toda consistente?

Você abre mão de uma transação distribuída única e usa uma saga: uma sequência de transações locais em que cada passo publica um evento que dispara o seguinte, e cada passo tem uma ação compensatória para desfazê-lo. A consistência vira eventual, então o trabalho de projeto é decidir o que compensar, o que repetir e o que escalar para um humano. Modele o fluxo explicitamente, por coreografia com eventos ou coordenado por um orquestrador.

Um two phase commit entre três serviços e três bancos significa segurar locks através da rede e ter um coordenador que pode travar tudo se cair, então eu não faria isso. Em vez disso o fluxo vira uma saga. Cada serviço faz a própria transação local e emite um evento, e cada passo tem uma compensação definida: se o envio não conseguir alocar, liberamos a reserva de estoque e estornamos ou cancelamos o pagamento. O importante é que compensação é uma ação de negócio, não um rollback; um estorno deixa um registro visível, e isso está correto. Para qualquer coisa com mais de uns três passos eu uso um orquestrador em vez de coreografia pura, porque com coreografia o fluxo real não mora em lugar nenhum e ninguém consegue responder onde um pedido travou. Um orquestrador me dá uma máquina de estados, timeouts por passo e um status consultável. Cada passo é idempotente e repetido com backoff, e tudo que esgota os retries cai numa fila de operações com o id do pedido, porque algumas falhas realmente precisam de uma pessoa.