Zopio

O que acontece com payment operation se Zopio estiver indisponível?

A resposta deve ser definida por flow antes de production. Alguns podem fail closed, outros continuar por paths pré-aprovados e outros aceitar trabalho não money-moving para depois. Regra crítica é não criar ambiguous ou duplicate execution.

01

A resposta direta

Toda dependency crítica precisa de failure contract: inicia new payment, lê state, processa callback, recupera como? Depende de duplicate risk e business impact.

02

Quando a abordagem atual é suficiente

Direct provider pode ter outage model mais simples. Com um provider e zero tolerância a intermediary failure, direct pode ser melhor.

03

Onde a pressão começa

Sem degraded design teams improvisam retries/bypasses. Timeout não prova que money não se moveu.

04

O que muda com uma camada de infraestrutura

Durable idempotency, provider recovery, queues, circuit breakers e clear states permitem continuidade; alguns flows podem ter emergency direct path.

05

O trade-off

Fallback paths adicionam complexity e podem ser untested shadow systems. Nem sempre são melhores que short outage.

06

Como decidir

Defina RPO, RTO e financial correctness por flow; simule falhas e escolha availability vs certainty.

07

Quando Zopio se encaixa

Zopio se encaixa somente se customer aceita seu papel no failure model e testa degraded behavior.

08

Um próximo passo prático

Execute game days e verifique messaging, state, provider lookup, reconciliation e recovery.

Conclusões práticas

Defina unavailable behavior antes de production.

Financial correctness pode superar availability.

Teste fallback como primary.