Just ask. We act.
DBSynth · Data access platform
DBSynth combines a near real-time PostgreSQL operational data store with configurable APIs, central access rules with an audit trail, and a central activity log. It runs in the client’s environment, uses the existing identity provider and leaves the core system unchanged.
One controlled path from core data to its consumers
Explore the architecture
Overview
Changes flow from the core system into the ODS. Applications and people read through MDDV. CAM limits each request to permitted rows and fields. CAM keeps the audit trail of the decision; LogSink keeps the activity log.
Already on site
The system of record. Its code and processes are not modified. Read workloads move away from its database.
Data foundation · built with the client
Carries every captured change as an ordered event from the core system to the ODS. Existing open-source technology, installed and configured.
Data foundation · built with the client
PostgreSQL operational data store. A near real-time replica of the core system data that consumers need. Built jointly with the client's team.
ODS page →Perikle product · access rights
Decides which rows and which fields each user may read. Rules are managed in one place and applied to every read, including totals and exports.
CAM page →Perikle product · access API and application
Publishes ODS tables as a REST API and as a web application. Resources and screens are defined in configuration, not developed one by one.
MDDV page →Perikle product · activity log
Central, searchable record of what each component did, including the ODS replication process. Best-effort by design: it never blocks a response. The audit trail of access decisions is CAM’s and has the opposite rule.
LogSink page →Already on site
Users sign in with Windows (Active Directory) or OAuth2. The platform does not introduce a separate user directory.
Already on site
Internal applications, integrations and reporting tools use the REST API. Business users work in the browser. Both see the same data under the same rights.
The core application and its processes are not modified.
It is picked up at the source and travels through Kafka as an ordered event.
Tables in PostgreSQL stay current in near real time. Consumers read the ODS, not the core.
The ODS process writes its activity to LogSink. The scope is decided during the ODS implementation.
Identity comes from Windows (Active Directory) or OAuth2.
Through the REST API or the web application. Both use the same configured resources.
Which rows and which fields this identity may read.
The read is served from the ODS. The core system is not involved.
LogSink keeps who read which data, and when.
Kafka and the PostgreSQL ODS. Existing open-source technology, installed and configured together with the client's team. Nothing proprietary in this layer.
MDDV, CAM and LogSink. Installed on top of the ODS. Together with it they form the complete platform.
The core system, the identity provider and the consumers. None of them is replaced.
The problem and the change
The same pattern appears wherever one central system holds the data that many others need. It is not specific to banking.
A practical starting point
We can identify the highest-load consumers, duplicated interfaces and access-control gaps before defining a target architecture.
Where DBSynth applies
The pattern is the same each time: data that many need, read through one controlled path. The components differ per case.
01 · Operational reads
Every consumer gets a current copy of core data through one API and one application. The core handles its own transactions and nothing else.
02 · Legacy retirement and retention
Data that must be retained after an application is retired moves, entity for entity, from each old database into one current platform. MDDV publishes it read-only, CAM governs it, LogSink records access. Ten ageing technologies become one supportable platform.
03 · Auditors, regulators and partners
Reviewers inside and outside the organisation get exactly the entities, rows and fields they are entitled to, through the application or the API. Export is separately permitted. Every access is recorded.
04 · Back-office screens
A table or view that needs a screen gets one from configuration: search, detail, related records and export, under the same rights as everything else.
Platform layers
The ODS alone gives a current copy of the data. The three products turn it into a controlled data access platform.
Perikle products · extension of the ODS
Data foundation · built with the client
ODS PostgreSQL operational data store, filled through Kafka in near real time. Existing open-source technology, installed and configured together with the client's team. A consulting engagement, not a product delivery. ODS →Already on site
Questions answered
Each change is captured once and sent through one controlled outbound stream into the ODS. Consumers do not connect to the core database.
Answered by ODS
Through a versioned, documented REST API. New resources are added in configuration.
Answered by MDDV
In a web application with search, list, detail and export over the same resources. No per-screen development.
Answered by MDDV
Rights are defined centrally, down to rows and fields. Users sign in with Windows (Active Directory) or OAuth2.
Answered by CAM
Activity across the platform is recorded centrally and can be searched.
Answered by LogSink
Engagement
Four delivery steps, with commercial and deployment details available below.
The core system, the data that consumers need, and the current access paths.
Replication is designed, installed and configured jointly with the client's team.
MDDV, CAM and LogSink are installed on the client's infrastructure and connected to the ODS.
Resources, screens and access rights are configured. Data, credentials and configuration remain with the client.
Contact
A short description of the core system and the data consumers is enough to start.
