Extend Global Torque with Event-Driven Cloud Run Workers
When a financial platform adds a CRM update, an accounting entry, or a customer notification, the tempting approach is to teach every service about every downstream provider. That works for the first connection. It becomes expensive as each provider adds credentials, error handling, release coupling, and a path through the core transaction.
Focused workers create loose coupling between components, making the system more flexible and easier to evolve. A service accepts a business change, publishes an event, and a separate Cloud Run worker handles one integration concern. The payment service does not need to know how Salesforce works. The payment service does not need to know which email provider an operations team prefers. Each worker can be released, scaled, and replaced around its own adapter while the financial workflow keeps its core responsibilities.
That makes each worker an independently deployable module. Teams can add or remove a worker without downtime or a platform rebuild. The modular architecture article describes how the same principle applies to product, provider and delivery configurations.
Start with a business event
Global Torque uses Distribute Finance to describe coordination across independent banks, custodians, identity providers, blockchains, administrators, and other providers. It is a financial coordination model, not shorthand for DeFi. The Distribute Finance overview explains why payment, asset delivery, and authoritative ownership records are separate facts that may finish at different times. The companion guide, Integrating with Torque: Less to Build, Less to Maintain, shows how a supported workflow can stay focused while each provider keeps its own role.
That model gives integrations useful business boundaries. Examples include:
- eligibility accepted under a particular policy version;
- payment confirmed against a provider reference; and
- ownership updated in the authoritative asset record.
An event says that an accepted change happened. It does not grant every consumer permission to perform a financial action. A worker validates the message, reloads the current state from the authoritative API or database it is allowed to use, and then decides whether its own side effect is still permitted. This keeps a CRM or reporting update from becoming an accidental source of settlement truth.
Why event-driven workers fit the platform
In an event-driven architecture, a producer records a change and consumers react independently. The Google Cloud event-driven architecture guide describes the pattern using asynchronous messages between components. In practice, that lets a request complete without waiting for every downstream provider to respond.
The useful distinction is between a business event and a raw database notification. PostgreSQL and the owning service API remain authoritative. A local transaction can save the accepted state change and an outbox record together; a relay can then publish the business message. Change-data-capture infrastructure may carry that record to Pub/Sub, but not every changed row is a business fact.
We give each audited worker its own push subscription and scoped service identity. That makes ownership and operations visible: one worker can process CRM updates, another can write accounting records, and a third can send notifications from the same event. By using Lambda or Cloud Run functions we shift most of infrastructure to AWS/GCP. The Pub/Sub Cloud Run tutorial covers receiving messages in a Cloud Run service, and Pub/Sub push delivery explains the authenticated HTTP delivery model if you interested in the details.
Illustrative architecture: the event labels show business concepts, not literal public API names. The linked PNG opens the full-resolution diagram. On a small screen, the table below expands the same architecture into a readable settlement lifecycle.
Apply the same pattern to settlement
The Settlement Intent product puts the asset, cash, parties, permitted route, delivery conditions, and required finality into one instruction. Torque Flow coordinates the process around those durable records. A worker can then own one integration step while the settlement record keeps the whole lifecycle visible.
Consider an illustrative exchange of 1,000 example units for €100,000. Conventional bank money, stablecoins, and tokenized deposits can be permitted cash options when the product and connected providers support them. Those rails are choices in a deployment, not interchangeable guarantees of atomic delivery versus payment.
| Accepted settlement fact | Focused worker responsibility | Integration benefit |
|---|---|---|
| Settlement intent recorded | Select and validate a permitted route for the asset, cash rail, parties, deadline, and required evidence. | Core services retain one durable instruction while adapters use a clear contract. |
| Permitted route selected | Check buyer funds and seller assets, recording reservations where the selected providers support them. | A bank, custodian, or cash-rail adapter can change independently of the settlement record. |
| Readiness accepted | Submit separately authorized payment and delivery instructions with stable effect identities. | Payment and delivery adapters can evolve independently while provider-safe retry rules remain explicit. |
| Provider evidence recorded | Track payment and delivery separately, store provider references, reload owned state, and verify required cash and asset finality. | Each provider adapter stays focused while operations can see which side is waiting. |
| Required finality accepted | Have the registry adapter verify prerequisites and update or confirm the authoritative ownership record. | Delivery status cannot silently become ownership; the registry integration keeps its own responsibility. |
| Ownership evidence accepted | Reconcile the cash, asset, and register records, then assign any unresolved exception and its next permitted action. | Teams can replace or repair one provider path without losing the core intent or completed evidence. |
The following object is illustrative, not a published API schema. It connects the stable instruction to one accepted payment fact while showing asset finality, ownership, and reconciliation still pending:
{
"schemaVersion": "illustrative.settlement.v1",
"settlementId": "settlement-example-001",
"progressState": "payment_confirmed_asset_finality_pending",
"buyerRef": "example-buyer",
"sellerRef": "example-seller",
"asset": {
"assetId": "example-tokenized-unit",
"quantity": "1000",
"deliveryState": "evidence_received",
"providerReference": "custody-delivery-example-001",
"evidenceReference": "asset-evidence-example-001"
},
"cash": {
"amount": "100000.00",
"currency": "EUR",
"selectedRail": "bank_transfer",
"acceptedPaymentFact": {
"eventType": "payment.confirmed",
"eventId": "payment-event-example-001",
"providerReference": "bank-payment-example-001",
"evidenceReference": "bank-evidence-example-001"
}
},
"finality": {
"paymentState": "accepted",
"assetState": "pending",
"requirement": "product_and_provider_agreement"
},
"ownership": {
"state": "pending",
"authoritativeRecordReference": "ownership-record-example-001"
},
"reconciliation": {
"state": "pending",
"cashAssetRegister": "not_yet_reconciled",
"exceptionOwner": "settlement-operations",
"nextAction": "Verify asset finality and update ownership record"
}
}The same settlementId correlates provider messages without treating one provider confirmation as proof of the whole settlement. The progressState, finality, ownership, and reconciliation fields are a derived progress view, not decision authority. The accepted payment fact tells a payment worker what was confirmed; it does not authorize issuance or mean the whole settlement is finished. A receiving worker reloads the state it owns and guards its next action against the instruction and prerequisites. Pending ownership and reconciliation remain visible until their evidence is accepted.
One settlement event can fan out to multiple independent subscriptions, so unrelated CRM, accounting, reporting, and notification projections can proceed in parallel. Financial stages still depend on their local guards and prerequisites. Replicas sharing one subscription distribute deliveries between themselves; they do not each receive a private copy. This distinction helps teams choose the right subscription layout and avoid duplicating a side effect accidentally.
Build a worker around one integration
An extension usually follows a short sequence:
- Agree on the supported event, schema version, access scope, and authoritative source. Define which business change the worker consumes and which result it owns.
- Implement a small HTTP receiver and an adapter for the target system. Validate the envelope, event identity, schema, and authorization before calling the provider.
- Deduplicate by a stable event or effect identity. Re-read current state before an irreversible or consequential action, because a message can be delayed or arrive after a newer state.
- Package the worker as a container with a scoped service identity and app-owned settings and secrets. Keep provider credentials and endpoint configuration in the deployment environment.
- Have the platform or infrastructure owner attach a separate authenticated push subscription. Configure retry and dead-letter behavior for the worker’s failure mode and retention needs.
- Rehearse duplicates, out-of-order delivery, delayed provider responses, worker restarts, and an unavailable downstream system before enabling the integration.
The platform or infrastructure owner provisions the subscription and delivery identity. A team can then add one connection by owning one small receiver and its provider behavior, while the core platform continues to own the financial workflow and its authoritative records.
Keep delivery reliable and outcomes honest
Pub/Sub delivery is at least once. A worker must tolerate duplicates and should not assume events arrive in business order. A stable effect identity, a durable deduplication record, and a current-state read make handling repeatable, but final safety also depends on the provider’s retry and idempotency guarantees. Verify those guarantees before enabling the worker. If an external payment or transfer may already have happened but the response is missing, reconcile the provider before trying again. A successful Pub/Sub acknowledgement confirms transport handling; it does not confirm financial settlement, legal finality, or ownership registration.
Retry and dead-letter controls are configured per subscription and worker. They are useful tools for bounded recovery, but they do not make every action safe to repeat. An unknown external outcome needs a provider-specific reconciliation path and an accountable owner.
AWS Lambda/Cloud Run also keeps operational ownership clear. Autoscaling lets each worker respond to its own request, CPU, and concurrency profile, with configurable bounds and zero idle instances by default. Teams can deploy a worker with health checks, a bounded identity, and configuration appropriate to its integration. A provider replacement then happens at the worker boundary rather than across every producer and frontend.
For a technical team, the next step is practical: choose one business event, one downstream responsibility, and one recovery rehearsal. Book a call with Global Torque to map that boundary and estimate the smallest maintainable worker for your platform.
