Inventory failure and payment failure compensation
Inventory rejected → no Payment call; Payment rejected → release then Failed
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
Semantic radar needs more MAP space.
mermaid alt/else structure (archify has no native block — flattened, bracket-tagged)
• alt Inventory rejected: messages 3-5 only, Payment is never called.
• else Inventory accepted: messages 6-9 run, then a nested alt: Payment rejected → messages 10-15 (release + InventoryReleasedEvent + OrderFailedEvent); else Payment accepted → messages 16-19 (PaymentAuthorizedEvent + OrderConfirmedEvent). The Payment-rejected and Payment-accepted branches are mutually exclusive.
Compensation contract
• If Payment is rejected, release is requested with the already-recorded ReservationId, and the release result and OrderFailedEvent are recorded in order.
• Both Inventory and Payment must return the first result when given the same deterministic ID again.