Advanced

Core banking adapter

The core banking adapter is the two-way replication bridge between a bank’s legacy core and Digital Twin. It is an integration pattern the bank (or its integrator) implements — not a Digital Twin product or service. Digital Twin remains the single authorizer of debits, so the two systems stay eventually consistent without the risk of double-spending.

Outbound — DTW → core

The adapter consumes Digital Twin’s authorized-transaction events from Kafka and applies them to the legacy core (when the core is available), keeping the core’s ledger in step.

Inbound — core → DTW

The adapter captures transactions from the core (Change Data Capture) and publishes them to Kafka so Digital Twin ingests them — the return leg of the two-way sync.

Eventual consistency, by design

The sync is asynchronous and eventually consistent — a deliberate choice. Requiring strong consistency would couple availability (core down or in batch ⇒ Digital Twin down too), which would defeat the 24×7 value proposition. The two ledgers converge and are reconciled; the core finalizes regulatory reporting after sync. Eventual consistency is a well-established distributed-systems trade-off (see references).

Reliable capture & batch replication

For a SQL-based core, the recommended capture is the transactional outbox pattern: a trigger writes each transaction to an outbox table inside the core’s own transaction (atomic with the business write), and the adapter polls that outbox and forwards to Kafka. This decouples capture from delivery and survives adapter downtime. Replicate in batches, not one message per transaction — bulk-replicating millions of rows one-by-one is needless Kafka overhead.

Who is responsible for a message that isn’t consumed?

A common question: Digital Twin emits an approved transaction for the core, but the core is down for an hour — or a day — or a bug in the adapter drops it. Should the producer monitor whether its message was consumed? No — and building that would be an anti-pattern. In publish/subscribe messaging the producer is deliberately decoupled from consumers: its responsibility ends when the broker durably accepts the message (in Kafka, acks=all guarantees durability — commit to the in-sync replicas — not consumption). Having a sender track per-consumer progress re-couples them and does not scale across many producers and consumers.

The three concerns are owned separately:

Durable publish

The producer’s job: get the message durably onto Kafka (acks=all), reliably produced via a transactional outbox. That is the whole of the sender’s liability.

Consumption & lag

The consumer’s job, observed with standard Kafka consumer-group lag monitoring — not by the sender. A stalled core adapter shows up as lag on its own consumer group.

Business correctness

Reconciliation — an independent end-state comparison of Digital Twin vs the core that raises alerts on divergence. It does not trust the pipe, so it catches every failure mode.

Why reconciliation, not just lag monitoring: a buggy adapter can commit the Kafka offset but never apply the transaction — consumer lag then looks healthy, so lag monitoring alone misses it. Reconciliation compares outcomes, so it detects the divergence regardless of how the transport failed. This is the classic end-to-end argument: correctness must be verified at the endpoints, not assumed of the channel (see references).

References

The terms and boundaries above are standard, published distributed-systems practice — not project-specific coinage. Primary sources:

Gregor Hohpe & Bobby Woolf, Enterprise Integration Patterns (Addison-Wesley, 2003) — Publish–Subscribe Channel, Guaranteed Delivery, and Dead Letter Channel: producers and consumers are decoupled through the channel.

Apache Kafka Documentation — Producer acks and delivery semantics: acks=all acknowledges once the record is committed to the in-sync replicas (a durability guarantee, distinct from downstream consumption). kafka.apache.org/documentation

Chris Richardson, Microservices Patterns (Manning, 2018) — the Transactional Outbox pattern for reliably publishing messages as part of a database transaction. microservices.io/patterns/data/transactional-outbox.html

Martin Kleppmann, Designing Data-Intensive Applications (O’Reilly, 2017) — Change Data Capture, logs and derived data, and eventual consistency.

Werner Vogels, “Eventually Consistent” (Communications of the ACM, 2009) — the eventual-consistency model for highly available distributed systems.

J. H. Saltzer, D. P. Reed & D. D. Clark, “End-to-End Arguments in System Design” (ACM Transactions on Computer Systems, 1984) — correctness is best verified at the endpoints, not guaranteed by the communication system: the rationale for reconciliation.

Machine-readable, in-depth docs for AI coding agents: see llms.txt and the messaging model (commands vs events, retry topics).

← Mainframe shadowing Stablecoins & blockchain →