Architecture and data

A blockchain operation can take time, fail temporarily, or go through several providers. Keeping an HTTP call open for the whole process would produce timeouts, duplicates and low resilience.

The API records the operation and publishes events. Specialized processes continue signing, execution, observation, reconciliation and notification.

This model allows retrying steps, isolating failures, scaling components independently, and rebuilding an operation's complete history.

The architecture defines two functional scopes:

• Control Plane, which administers tenants, credentials, networks, assets, providers, contracts, limits, fees and policies;
• Data Plane, which processes users, wallets, quotes, operations, signing, execution, ledger and events.

The Data Plane uses an approved configuration version. An administrative change does not modify an operation already in progress.

These terms describe parts of ChatterPay B2B, not Kubernetes' internal control plane.

A modular monolith lets you keep clear domain boundaries without introducing unnecessary internal networking, deployments, observability and distributed consistency from day one.

API, workers, observers, webhooks and reconcilers can run as separate processes when they need different scaling, isolation or recovery. Physical separation is applied when it brings a concrete operational benefit.

The financial domain needs:

• atomic transactions;
• unique constraints;
• referential integrity;
• concurrency control;
• an append-only ledger;
• an auditable history;
• reproducible queries.

PostgreSQL covers those needs and allows storing flexible structures via jsonb.

Free-tier MongoDB Atlas is useful in other contexts, but private connectivity requires a dedicated cluster. Running MongoDB inside GCP also adds infrastructure and operations. For the first self-hosted profile, Cloud SQL PostgreSQL reduces cost and complexity.

The operational ledger is ChatterPay B2B's internal, chronological financial record. It is information persisted in the database: it records movements, but it is not a wallet and does not custody crypto assets. Through append-only movements, it represents which amounts were reserved, sent, received, charged as a fee, consumed as gas, refunded or adjusted for each operation, asset, tenant and beneficiary.

Its purpose is to explain an operation's economic outcome. The blockchain provides the on-chain facts, such as a confirmed transaction and its amounts; the Operation keeps the workflow; the ledger keeps how those facts financially impact the system's and the Partner's internal accounts.

Reconciliation is the verification process that compares what was expected with what actually happened. It contrasts the Operation and its legs, the ledger's movements, the transactions observed on each blockchain, and the states or charges reported by providers like LI.FI.

When the data matches, it confirms the financial result and releases the corresponding reservations. When there is a difference — for example, actual gas different from the estimate, a refund, a different received amount, or an ambiguous transaction — it records the discrepancy and generates the applicable compensating adjustment or manual review. Reconciliation uses the ledger; it is not another record of funds.

Transactional Outbox is a widely used architectural pattern for coordinating database changes with the asynchronous publication of messages. It is a design pattern, not a protocol or a specific product.

The operation and the pending event are saved atomically in the same PostgreSQL transaction. An independent process reads that Outbox and publishes the event to Pub/Sub.

Each consumer records in an Inbox the identifiers of the messages it already processed. This allows detecting repeated deliveries and applying the result only once.

This lets the platform assume at-least-once delivery: a message may repeat, but the financial result must not be duplicated.

Pub/Sub distributes asynchronous work and Cloud Tasks schedules retries or future actions. PostgreSQL keeps the durable state.

Kafka would add an operational platform the initial volume does not justify. An engine like Temporal would duplicate part of the workflow state before the real complexity has been shown to require it.

The architecture leaves an orchestration interface that allows incorporating another engine later.

Each operation is split into persisted steps, such as validation, reservation, signing, simulation, submission, observation, accounting and notification.

Each worker executes a bounded transition, saves the result and publishes the next event. If the process restarts, another worker continues from the durable state.

Operations with swaps or bridges add independent legs for each transaction or stage. A leg is an executable unit with its own network, provider, amount, payload, hash and status; several legs make up the result of a single Operation.

The operation moves to an ambiguous-result state, such as broadcast_unknown.

The platform keeps the signed payload and looks for evidence via hash, nonce, receipts and on-chain observation. It only resubmits the same artifact when it is safe to do so.

It does not create a second transfer or rebuild another transaction with a different nonce.