Two-node simulation tests identity boundaries

What the public implementation shows

The repository ships separate Node A and Node B compose files, adapter configurations, ports, peer routes, and PostgreSQL databases.

Each simulated participant owns its own gateway state while exchanging messages through the same public APIs used for switch-facing flows. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA realistic local topology should preserve the identities and boundaries production logic depends on.

The decision behind the mechanism

Two nodes prevent local self-routing from colliding with transaction-level de-duplication and make directionality visible.

A single-node loopback can use the same TxId on both sides of a transaction and falsely trigger controls designed for independent participants. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Use separate databases per participant node.
• Give every node explicit peer routing.
• Keep adapter and credentials node-specific.
• Never disable de-duplication merely to make loopback work.

How the control should be operated

Test runs should capture both node records, message directions, callbacks, and failure injection so discrepancies are attributable.

Developers can validate distributed payment behavior without weakening production identity rules for local convenience. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.