LEARN. PRACTICE. GROW.Apply the entire revision before advancing
The exercise transaction produces three events at the same revision: PUT rule, DELETE obsolete, and PUT fresh. If the handler updates its cursor after the first event and skips every remaining event at a lower or equal revision, it loses part of the transaction. The teaching consumer compares each event against the cursor committed before the batch, stages a working copy, and publishes the new set and cursor only after completion. Observation checks three applied events and equality with a complete read. The adapter must preserve order and batch boundaries; knowing that the subscription is connected is insufficient.
Inject a failure and observe published state
The lab injects an exception after staging the first event. The working copy changed, but published cache and cursor remain unchanged. It then applies the same batch without the exception and compares the result with the source. This exercise demonstrates handling of one specific failure before in-memory publication. It simulates neither a crash between two disk writes nor power loss. When reviewing a persistent component, identify interruption points between state and checkpoint and require a resumption contract. The teaching result provides a basis for specifying those tests without establishing that they have already been performed.
Distinguish cache replay from business effects
The code deliberately reapplies the already committed batch. Because revisions do not exceed the cursor, it applies zero additional cache events. This does not mean the server spontaneously duplicated events within the same watch; the test itself resubmitted the saved batch. Nor does it demonstrate single execution of external payments, messages, or files. A state cache can replace a value without repeating an external operation, while a business handler may produce irreversible effects. Before reusing one in an exercise, identify destinations and the replay contract. A test label on a key does not prevent code from contacting a real partner.
Exercise disconnection, removals, and scope
The first watch ends and the script performs two changes while the consumer is disconnected. One updates rule and the other deletes fresh. Resuming after the last applied cursor recovers both events and makes the consumer match the source again. In the final control, the script writes one key outside /dr/cache/ and another inside that prefix. Only the second should enter the set. These steps check continuity and scope with concrete operations, including DELETE. They are neither load tests nor maximum-latency tests. For a real consumer, add representative volume, operational identity, timeouts, and error handling according to defined objectives.
Include rebuilding and backlog in objectives
A rebuilt cache may allow service resumption while work remains pending. In an exercise with 2400 backlogged events, sustainable capacity of 300 per minute, and arrivals of 100 per minute, net backlog-clearance capacity is 200 per minute. The estimate is twelve minutes, assuming constant rates and no other constraints. Record those assumptions and distinguish function availability from complete backlog clearance. Along a sequential path, also add restore, rebuilding, and validation when all are necessary for acceptance. A more expensive optimization should be approved with justified benefit to the service objective and its dependencies.
Handover and resumption decision workshop
Allow forty-five minutes and assign APS, consumer-owner, and technical-PM roles. In fifteen minutes, run the lab and connect each observation to its prediction. Use another fifteen to review a case with a correct cache, untested persistence, and backlog beyond the agreed window. During the final fifteen, present a resumption decision, missing condition, owner, and deadline in English. Use the worksheet below to preserve evidence and limitations. The ten local groups do not replace real-consumer tests or specialist review. These examples are fictional; they describe neither BNP Paribas processes nor its authorizations.
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.A transaction updates two rules and deletes a third at the same revision. The consumer should apply the set before advancing its cursor; acknowledging only the first event can leave an old rule active.
Common pitfalls
Advancing the cursor midway through a revision; confusing an in-memory exception with crash recovery; inferring unique external effects; ignoring new arrivals when calculating catch-up time.
Related topics: Restore: recovered point and integrity · Snapshot, identity, and recovered point · Revisions, watches, and controlled resumption
Accepting a consumer requires correct state, continuity, and demonstrated failure handling within the intended scope. Capacity, persistence, and external effects need evidence beyond the local example.
Reference: API guarantees · BigSavant recovery 2026-09; PostgreSQL 18, etcd 3.6 and selected AWS/Azure behavior