Enterprise integration & safe change — working copy

Draw a source case service and a receiving work queue. Identify the authoritative record, business ID, operation ID, caller identity, permitted scope, freshness requirement and recovery owner. Choose synchronous, queued or batch exchange. Describe the state shown to the operator if the receiver commits but its acknowledgement is lost.

The source transaction updates case-42 and inserts an outbox event together. Its injected failure occurs between those statements. Verify that the status remains new and there are zero outbox rows after rollback.

The receiving transaction stores an event identity and creates a task together. Its injected failure occurs before task insertion. Verify that the identity row also rolls back, so a later delivery can still create the task. Explain why inserting the deduplication marker in a separate transaction could lose work.

The lab delivers event-42 twice. Expect created, then duplicate, with exactly one receiving task. It then reuses event-42 for case-99; verify the conflict is rejected.

In a copy of the lab, generate a new event ID for every retry and inspect the resulting task count. Explain why this changes the meaning of a retry. Define the key's tenant scope and retention before applying the pattern to a real service. A local outbox and receiver do not prove distributed exactly-once processing, ordering or safe remote side effects.

For an independent experiment, save this as integration_experiment.py beside the downloaded lab and run python3 integration_experiment.py:

import runpy
import sqlite3
lab = runpy.run_path("fde-enterprise-integration.py")
source = sqlite3.connect(":memory:")
receiver = sqlite3.connect(":memory:")
try:
    lab["prepare"](source, receiver)
    payload = lab["commit_case"](source, "original")
    print(lab["receive"](receiver, "original", payload))
    print(lab["receive"](receiver, "original", payload))
    print(receiver.execute("SELECT count(*) FROM tasks").fetchone()[0])
    print(lab["receive"](receiver, "new-retry-id", payload))
    print(receiver.execute("SELECT count(*) FROM tasks").fetchone()[0])
finally:
    source.close()
    receiver.close()

Explain why the counts move from one to two when the operation identity changes, even though the business payload does not.

Fill a table for invalid payload, denied permission, connection failure, unknown write outcome and overload. For each, record retryability, maximum attempts, elapsed-time budget and next owner. Include backoff, jitter and reconciliation. Define queue-age and capacity limits. Before replay, recheck current authorization, version, expiry and operation identity.

Changed condition: the source permission was revoked while work waited. State why the stored event alone is insufficient authority to execute now.

The migration adds owner_display_name beside owner_name, backfills old rows and maintains both on new writes. Inspect old and new reader results. The deliberately broken scenario writes Queue B only to the new field, leaving the old reader with Unassigned. Explain why an old application image would not repair that semantic incompatibility.

Design a large-table version: bounded batches, restart cursor, safe reruns, concurrent-write handling, lag and lock monitoring, rollback/forward-repair decision. State the evidence required before removing the old column. Do not run this example as a migration against an existing database.

Packet: interface map, contract with units/errors, operation-key policy, before/after rows, old/new compatibility matrix and reconciliation runbook.

Have a reviewer select duplicate delivery, conflicting payload, old consumer or revoked permission. Predict the result, run the relevant local check and explain the safe next action. Record observed acceptance and unresolved work with owners. Do not describe the synthetic exercise as a partner service guarantee.

References: HTTP semantics, AWS transactional outbox, AWS retries, Evolutionary database design. Checked 2026-10-23.