APRENDER. PRATICAR. EVOLUIR.Aplicar a revisão inteira antes de avançar
A transação do exercício produz três eventos na mesma revisão: PUT rule, DELETE obsolete e PUT fresh. Se o handler atualizar o cursor após o primeiro evento e ignorar todos os restantes com revisão menor ou igual, perde parte da transação. O consumidor didático compara cada evento com o cursor confirmado antes do lote, prepara uma cópia de trabalho e só publica o novo conjunto e cursor depois de concluir. A observação verifica três eventos aplicados e igualdade com uma leitura completa. A ordem e a fronteira do lote precisam de ser preservadas pelo adaptador; não basta saber que a subscrição está ligada.
Injetar uma falha e observar o estado publicado
O laboratório injeta uma exceção após preparar o primeiro evento. A cópia de trabalho foi alterada, mas a cache publicada e o cursor permanecem iguais. Depois aplica o mesmo lote sem a exceção e compara o resultado com a origem. Este ensaio demonstra o tratamento de uma falha específica antes da publicação em memória. Não simula um crash entre duas escritas em disco nem uma falha de energia. Ao rever um componente persistente, identifica os pontos de interrupção entre estado e checkpoint e exige um contrato de retoma. O resultado didático é uma base para formular esses testes, sem provar que já foram realizados.
Distinguir replay da cache e efeitos de negócio
O código reaplica deliberadamente o lote já confirmado. Como as revisões não ultrapassam o cursor, aplica zero eventos adicionais à cache. Isto não significa que o servidor tenha duplicado eventos espontaneamente no mesmo watch; o próprio teste voltou a entregar o lote guardado. Também não demonstra execução única de pagamentos, mensagens ou ficheiros externos. Uma cache de estado pode substituir um valor sem repetir uma operação externa, enquanto um handler de negócio pode produzir efeitos irreversíveis. Antes de o reutilizar num ensaio, identifica os destinos e o contrato de repetição. Uma etiqueta test numa chave não impede o código de contactar um parceiro real.
Ensaiar desconexão, exclusões e âmbito
O primeiro watch termina e o script executa duas alterações enquanto o consumidor está desligado. Uma atualiza rule e outra elimina fresh. Ao retomar depois do último cursor aplicado, o consumidor recupera ambos os eventos e volta a coincidir com a fonte. No controlo final, o script escreve uma chave fora de /dr/cache/ e outra dentro desse prefixo. Só a segunda deve entrar no conjunto. Estes passos verificam continuidade e âmbito com operações concretas, incluindo DELETE. Não constituem um ensaio de carga ou de latência máxima. Para um consumidor real, acrescenta volume representativo, identidade operacional, timeouts e tratamento de erros conforme os objetivos definidos.
Incluir reconstrução e atraso nos objetivos
Uma cache reconstruída pode permitir retomar o serviço enquanto ainda existe trabalho pendente. Num exercício com 2400 eventos de atraso, capacidade sustentável de 300 por minuto e chegada de 100 por minuto, a capacidade líquida para eliminar o atraso é 200 por minuto. A previsão é doze minutos, admitindo taxas constantes e ausência de outras restrições. Regista essas hipóteses e distingue disponibilidade da função de eliminação completa do atraso. No caminho sequencial, soma também restauro, reconstrução e validação quando todas são necessárias à aceitação. Uma otimização mais cara só deve ser aprovada com benefício justificado no objetivo do serviço e nas dependências.
Oficina de handover e decisão de retoma
Reserva quarenta e cinco minutos e distribui os papéis de APS, responsável do consumidor e PM técnico. Em quinze minutos, executa o laboratório e associa cada observação à previsão. Usa outros quinze para rever um caso com cache correta, persistência por ensaiar e atraso acima da janela acordada. Nos quinze finais, apresenta em inglês uma decisão de retoma, condição em falta, responsável e prazo. Usa a grelha abaixo para preservar evidência e limitações. Os dez grupos locais não substituem testes de consumidores reais ou revisão especializada. Os exemplos são fictícios; não descrevem processos ou autorizações da BNP Paribas.
RECOVERY ACCEPTANCE WORKSHEET / GRELHA DE ACEITACAO
Authorized source / Origem autorizada:
Scope and read revision / Ambito e revisao da leitura:
Expected keys, values and absences / Chaves, valores e ausencias esperados:
Last fully applied revision / Ultima revisao integralmente aplicada:
Disconnect and DELETE evidence / Evidencia de desconexao e DELETE:
Handler failure and restart evidence / Evidencia de falha e retoma:
Persistent checkpoint contract still to test / Contrato duravel por ensaiar:
Backlog, arrival rate and sustainable capacity / Atraso, chegada e capacidade:
External effects and controlled destinations / Efeitos externos e destinos:
Decision, owner and reassessment deadline / Decisao, responsavel e prazo:
English briefing example:
Cache recovery passed in the local exercise. The production consumer,
durable checkpoint behavior and business acceptance remain open.
The named owner will provide the missing evidence before resumption.Uma transação atualiza duas regras e elimina uma terceira na mesma revisão. O consumidor deve aplicar o conjunto antes de avançar o cursor; confirmar só o primeiro evento pode deixar uma regra antiga ativa.
Armadilhas comuns
Avançar o cursor a meio de uma revisão; confundir exceção em memória com crash recovery; inferir efeitos externos únicos; ignorar chegada de novos eventos ao calcular recuperação do atraso.
Tópicos relacionados: Restauro: ponto recuperado e integridade · Snapshot, identidade e ponto recuperado · Revisões, watches e retoma controlada
Aceitar um consumidor exige estado correto, continuidade e tratamento de falhas demonstrados no âmbito pretendido. Capacidade, persistência e efeitos externos precisam de evidência adicional à do exemplo local.
Referência: API guarantees · DR recovery 2026-09; PostgreSQL 18, etcd 3.6 and selected AWS/Azure behavior