# F1.2 — Metas de perda e de retorno (RPO/RTO) A pendência que resta da F1.2. A decisão de SaaS foi fechada em `f1-2-decisao-saas.md`; esta define se a replicação é síncrona ou assíncrona, e com isso toda a F1.7. Escrito em 17/08/2026, sobre medição da base real. - **RPO** — quanto de dado se aceita perder numa queda abrupta. - **RTO** — em quanto tempo o sistema precisa voltar. --- ## A exposição medida `scripts/medir-exposicao-parada.sql`, sobre os últimos 90 dias. Reproduzível: ```bash docker compose exec -T mysql mysql -uroot -proot franquiabv_dev -t \ < scripts/medir-exposicao-parada.sql ``` | | Média | Pico | |---|---:|---:| | Vendas por dia | 612 | 1.161 | | Faturamento por dia | R$ 56.861 | R$ 107.375 | | Vendas no minuto | 1,64 | **9** | | Faturamento no minuto | R$ 152,70 | **R$ 1.305** | | Agendamentos por dia | 1.341 | | Concentração, que define quando uma parada dói: | Dia | Vendas | Faturamento | |---|---:|---:| | **Sexta** | 982,8 | R$ 89.796 | | **Sábado** | 904,8 | R$ 87.372 | | Quinta | 735,6 | R$ 67.879 | | Quarta | 597,2 | R$ 54.684 | | Terça | 564,8 | R$ 51.968 | | Segunda | 447,1 | R$ 40.907 | | **Domingo** | **50,2** | **R$ 5.424** | Por hora, os picos são **11h** (70,4 vendas) e **17h–19h** (65,3 / 64,0 / 60,4). O histórico cobre 11 anos: 2,2 milhões de vendas finalizadas desde junho de 2015. --- ## RPO — quanto custa perder os últimos segundos Convertendo o pior minuto observado em 90 dias — 9 vendas, R$ 1.305 — para janelas de atraso de replicação: | Atraso na queda | Vendas perdidas | Valor | No dia médio | |---|---:|---:|---:| | 1 s | 0,15 | R$ 22 | ~R$ 3 | | 10 s | 1,5 | R$ 218 | ~R$ 25 | | 30 s | 4,5 | R$ 653 | ~R$ 76 | | 60 s | 9 | R$ 1.305 | ~R$ 153 | **A conclusão desconforta um pouco: perder até um minuto de vendas custa pouco mais de mil reais no pior cenário possível.** É dinheiro, mas é recuperável — a venda aconteceu há segundos, o barbeiro lembra, o cliente está na cadeira. O problema não é o valor. **É a perda ser silenciosa.** Uma venda que sumiu sem ninguém saber vira divergência de caixa no fim do dia, sem explicação e sem como reconstruir. ### O que a replicação síncrona resolve — e o que não resolve Replicação síncrona dá RPO zero: a venda só confirma depois de gravada em dois nós. Custo: latência em toda escrita, para sempre. Dentro do mesmo datacenter são 1–3 ms, o que é irrelevante aqui. Para um nó remoto, 10–30 ms ou mais, o que já se nota no PDV. **Mas há uma armadilha no modo de falha que vocês realmente tiveram.** O evento de 2025 foi um datacenter inteiro fora do ar por 36 h. Um nó síncrono **no mesmo datacenter** teria caído junto. Quem sobreviveu foram os nós remotos — e manter esses síncronos é exatamente o que cobra latência em toda venda. Ou seja: para o desastre que motivou tudo isso, **RPO zero não é alcançável a custo razoável.** O nó que sobrevive é sempre o assíncrono. ### A alternativa que vale mais que a replicação síncrona Um **relatório de reconciliação pós-promoção**: depois de um failover, o sistema compara o que o primário antigo confirmou com o que o novo recebeu, e lista o que ficou pelo caminho. Custa uma vez e transforma perda invisível em tarefa de dez minutos: alguém redigita cinco vendas com a lista na mão. Replicação síncrona remota, comparada a isso, cobra latência em cada venda, todo dia, para sempre — e ainda assim não cobre a perda do datacenter. --- ## RTO — quanto custa ficar fora Aqui há uma distinção que muda a conta, e que os números não mostram sozinhos. **Barbearia parada não perde a venda.** O barbeiro corta o cabelo do mesmo jeito. A comanda vira papel e é lançada depois. O faturamento de R$ 152/minuto **não evapora** numa parada curta — ele fica represado. O custo real da parada é outro, e cresce de forma muito desigual: | Duração | O que acontece | Custo | |---|---|---| | **< 5 min** | Comanda espera. Ninguém fora da loja percebe | Desprezível | | **5–30 min** | Fila no caixa; agenda consultada por telefone; ~2 agendamentos por minuto falham no app | Atrito | | **30 min – 2 h** | Agenda vira caos: cliente chega e ninguém sabe quem está marcado. Fechamento de caixa emperra | Real | | **> 2 h** | Operação improvisada em papel nas 32 unidades. Reconciliação depois custa dias | Alto | | **36 h** | O que aconteceu em 2025 | O que motivou tudo isto | **A curva é o argumento.** Sair de 36 h para 30 min captura quase todo o valor disponível. Sair de 30 min para 30 s captura muito pouco, e multiplica a complexidade do desenho. Investir em RTO de segundos aqui seria pagar caro pelo trecho barato da curva. --- ## Metas recomendadas | | Meta | Por quê | |---|---|---| | **RPO** | **0 para falha de máquina** · **≤ 30 s para perda de datacenter** | Nó síncrono no mesmo datacenter custa 1–3 ms e cobre disco e kernel. Para perda do datacenter, os R$ 653 do pior caso não justificam latência remota em toda venda | | **RTO** | **≤ 5 minutos, automático** | Abaixo de 5 min a operação absorve sem ninguém de fora perceber. O prêmio inteiro é nunca mais chegar a horas | Desenho que decorre disso: - Um **standby síncrono no mesmo datacenter** da produção — RPO zero para falha de máquina, latência desprezível. - Os **nós remotos assíncronos** — BVIP e Orange Pi. São eles que sobrevivem à perda do datacenter, com até ~30 s de atraso. - **Promoção automática** com quórum, e troca de tráfego por DNS com verificação de saúde (~30 s), o que cabe folgado nos 5 minutos. - **Relatório de reconciliação** obrigatório após qualquer promoção. ### O que isso dispensa Não é preciso replicação síncrona para os nós remotos. Essa era a opção cara, e os números mostram que ela compra pouco: no pior minuto de sexta-feira, o que se protege são R$ 1.305. --- ## Um achado colateral: a janela de manutenção Domingo tem **50,2 vendas** contra 982,8 da sexta — 5% do movimento. É a janela óbvia para o corte da F1.8 e para qualquer manutenção que exija parada. Um corte de duas horas no domingo de manhã atinge cerca de **4 vendas**. O mesmo corte na sexta à tarde atingiria mais de 130. Isso responde, sem precisar de discussão, quando o corte acontece. --- ## Para fechar Três perguntas, e só a primeira é realmente de negócio: 1. **Cinco minutos de parada automática é aceitável?** Se a resposta for "só se for menos", o desenho muda e encarece — e vale saber por quê antes de pagar. 2. **A produção tem um segundo nó no mesmo datacenter da Hostinger?** Define se o standby síncrono é possível como descrito. 3. **Quem redigita as vendas do relatório de reconciliação?** Precisa ter dono antes do primeiro failover, senão o relatório é gerado e ignorado.