CUSTOMER 360

Serving a Customer Golden Record from Core Banking, Cards and Loan Journeys

How Oracle, PostgreSQL and MongoDB changes become a governed real-time customer view without erasing source authority.

A service agent could see a current account in one screen, card status in another and a loan request in a third. The customer expected one conversation; the systems presented three identities and three clocks.

Start with one workload | Scale into a complete platform | Open Source Freedom | Enterprise-Grade Operations.

Published | July 2025

One customer journey, several systems

A service agent could see a current account in one screen, card status in another and a loan request in a third. The customer expected one conversation; the systems presented three identities and three clocks.

Moving all records into one store would not decide which name, address or phone number was authoritative. A faster pipeline could make contradictory data arrive faster without making it more useful.

The turning point

The architecture separated capture, identity resolution, survivorship and serving. Oracle remained authoritative for core banking, PostgreSQL for cards and MongoDB for loan journeys; the golden record carried lineage back to each decision.

The team used OSS Manager to make multi-source CDC customer golden-record projection reviewable and repeatable. The engine still owned its native behaviour; the control plane made intent, prerequisites, execution and evidence visible to the people responsible for the service.

What had to become explicit

• The service boundary: CDC connectors capture approved customer changes from Oracle core banking, PostgreSQL credit cards, and MongoDB loan requests into governed Kafka topics. A resolution and projection layer builds a versioned golden record for a low-latency serving store while source systems remain authoritative.
• The operational controls: source ownership, field-level classification, consent and purpose, identity resolution, schema contracts, ordering, idempotency, survivorship rules, deletes, DLQ, replay, lineage, and reconciliation.
• The capacity conversation: change rate by source, event and customer size, topic partitions, connector tasks, identity-resolution cost, serving-store working set, retention, replay burst, and recovery bandwidth.
• The human boundary: who may observe, who may approve, who may execute, and who decides whether the application is ready.
  

The architecture that changed the conversation

The diagram is deliberately centred on the decision the team had to make. It is not a product inventory. It shows where authority sits, what crosses the boundary, and where a failed assumption must stop the workflow.

The practical design choices

These choices are intentionally small enough to review and test. They keep the architecture tied to operating behaviour instead of allowing a visually impressive diagram to hide unclear ownership.

What OSS Manager changed - and what it did not

OSS Manager brought discovery, planning, guarded execution and normalised status into one path for Oracle, PostgreSQL, MongoDB, Kafka Connect, and a serving store. It did not replace the engine's correctness model or the application's responsibility for data semantics.

• Before change, validate versions, hosts, identities, artifacts, topology and the recovery boundary without mutating the service.
• During change, persist progress, expose stop conditions and prevent a partial result from being mistaken for success.
• After change, observe source-log retention; connector lag; task health; schema failures; unmatched identities; conflict count; DLQ volume; golden-record freshness; serving latency; reconciliation difference and run representative application journeys, not only process checks.
• For recovery, protect the last known-good authority and require an explicit decision before promotion, rollback or destructive cleanup.

The failure modes worth rehearsing

The test plan should make room for source-log expiry, duplicate or out-of-order change, identity false match, schema-breaking change, consent violation, poisoned record, sink backpressure, partial customer view, and replay storm. The purpose is not to produce a longer checklist. It is to learn whether operators can recognise the failure and choose the safe next action while the evidence is incomplete.

A human operating model

L1 operators need a plain-language answer to what is healthy, what is delayed and whether a change is in progress. Platform engineers need topology and evidence. Application owners need to know what users will experience. A useful platform connects those views without giving every person the same privileges.

Where this pattern earns its place

Media and OTT

This pattern is relevant where teams need regional continuity, burst traffic, low-latency serving and predictable recovery. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.

Retail

This pattern is relevant where teams need campaign peaks, catalogue freshness, transaction continuity and rapid rollback. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.

Telecom

This pattern is relevant where teams need high event volume, distributed operations, identity boundaries and service assurance. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.

The lesson we would carry into the next project

The valuable product was not a giant customer row. It was a current, explainable view that a service, risk or experience team could use with confidence.

The strongest open-source platforms are not the ones with the most automation. They are the ones where automation makes ownership, risk and recovery easier for people to understand.