LEARN. PRACTICE. GROW.1. Start with the outcome and states
In a fictional fund-instruction platform, the business wants each authorized instruction to produce a movement and a retrievable outcome. Receiving a message, validating fields, accepting work and confirming the movement are different events. Model them before debating codes or tools. A received state should not suggest that the movement already exists. HTTP 202 allows processing to remain pending; the application contract must explain how the outcome will be followed. For every state, record its producer, supporting evidence and permitted transitions. A client timeout describes a missing response to that attempt. The operation can continue on the server. Separating operation state from client knowledge avoids treating silence as definitive rejection.
2. Distinguish identity, content and intent
The analyst receives three records: client A, key K7, 100 units; client A, key K7, 100 units; client B, key K7, 100 units. The fictional contract defines identity by authorized client and key. The first two records are attempts at one operation; the third belongs to another identity. That does not grant A access to B’s result. Diagnostic correlation also does not replace authentication and authorization. Add key origin, scope, persistence across attempts and operation lookup to the data dictionary. Two requests with identical content can represent two legitimate instructions. If their intent differs, merging them solely by a content hash can discard work requested by the business.
3. Repetition and amendment are different decisions
Instruction A/K7 was accepted for 100 units. A later request uses A/K7 and 140 units. The exercise policy rejects different content for the same identity while retaining the earlier operation. Repeating with 140 therefore does not silently amend the accepted instruction. An amendment needs its own process, subject to current state and applicable authority. Also identify which fields participate in comparison. Display whitespace, diagnostic fields and business values need not serve the same purpose. Do not invent normalization rules during an incident. Prepare examples with the team: matching content, changed business content, another client and new intent with identical content. Record each expected outcome and validate it with producers and consumers.
4. Place failure at a concrete point in the sequence
Consider a local model with two writes: record the movement and store the handled identity. If the movement commits and failure occurs before the second write, a repeat can appear new. Reversing the order without further conditions does not solve the problem either: storing identity and failing before the movement can prevent work still required. In the exercise, both writes belong to one local transaction: either both commit or neither does. Request evidence for failure before commit and response loss after commit. In the first case, a repeat can still create the movement; in the second, it should retrieve the stored result. Idempotency concerns the intended effect; it does not require byte-for-byte identical responses or prohibit another diagnostic record.
5. Keep evidence within its transaction boundary
Now an external partner produces the movement. The local database confirms the outgoing message, but the partner’s response is lost. A local transaction does not automatically undo an effect committed by that partner. Analysis needs an inter-service contract: destination-recognized identity, reliable lookup, repeat handling and reconciliation while execution remains unknown. A lookup screen fed by a delayed copy may not prove nonexecution. In the fictional case, the secondary feed arrives up to five minutes later; not finding the operation there after ten seconds leaves the outcome unresolved. Define who investigates, which source permits a conclusion and which actions depend on it. Never turn a local two-write demonstration into a single-execution promise across independent systems.
6. Protection also has a time window
The client can retry for 72 hours, but the proposal retains identities for 24. There is a gap between permitted behavior and the memory used to recognize it. Declaring that a key exists is insufficient. Compare windows, reference clock, expiry, result lookup and treatment of old requests. In the exercise, age starts at first acceptance and protection covers ages below 24 hours; exactly 24 is outside it. This boundary is an explicit teaching choice, not an HTTP rule or universal retention recommendation. The project can align windows or route old requests through reconciliation that prevents unintended automatic execution. Storage cost and operating needs enter the decision with defined owners. Example with explicit offsets: from 24 October at 12:00+01:00 to 25 October at 12:00+00:00, 25 hours elapse because the instants are 11:00 UTC and 12:00 UTC the following day. A rule covering age below 24 hours excludes the second attempt. The example takes offsets as input; it does not infer a country’s rules. Also define the event starting the clock, boundary inclusion or exclusion and the clock source.
7. Confirm what cancellation means
An operation is running when the user requests cancellation. The interface reports cancellation request received, but that does not demonstrate that the movement was prevented. Specify the point beyond which cancellation cannot prevent the effect and the source that decides event order. Under the fictional policy, an atomic service decision resolves the race: if cancellation wins before commit, the outcome is cancelled with no movement; if commit wins, the outcome is completed and cancellation is rejected as late. Notification arrival at the screen does not determine that order. If a completed movement must be reversed, that is a new authorized business action with its own history. Deleting the earlier record destroys the explanation of what occurred.
8. Exercise: prepare the recovery decision
Before reading the sample analysis, classify four events under the local contract: A/K7 already has committed movement M7 and loses its response; A/K8 fails before either write commits; A/K7 returns with 140 instead of 100 units; B/K7 arrives as a new authorized instruction. Decide which identity exists, whether a movement may be created and what information should be returned. Sample analysis: repeating A/K7 retrieves M7; A/K8 can execute because nothing committed; amended A/K7 needs a conflict without changing M7; B/K7 is another identity and can create its movement. Then change one condition: M7 belongs to an external partner and only a delayed feed is available. Explain why the resend decision no longer follows from the local database alone. Produce a state table, assumptions, sources of truth and open questions for business, development and APS.
Exercise files
Original Python exercise with instructions, local transactions and cancellation schedules. Requires Python 3.10 or later. Includes reasoned solutions and model limits.
A response is lost after the movement commits. Retrieving the outcome for the same identity avoids confusing another attempt with another instruction.
Common pitfalls
Treating equal content as equal intent; accepting changed content under the same key; confusing timeout with rejection; generalizing a local transaction; cancelling only in the interface; ignoring identity expiry.
Related topics: Version-specific traceability · Interface acceptance
A recovery contract connects identity, effect, state, time and authority. Examples should demonstrate those connections where the outcome can become unknown.
References
- PMI-PBA Examination Content Outline · Public five-domain ECO: body copyright2013; back cover copyright2017 / PRA-206-2017_PBA (07/17). No new exam effective date inferred.
- HTTP Semantics · RFC 9110, June 2022; fixed publication. Partial errata triage on 2026-10-09; complete live errata register unavailable.
- Making retries safe with idempotent APIs · Public article inspected 2026-10-09; contextual design discussion, not a PMI exam requirement