Registry data management subsystem

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

1. General description

A subsystem whose purpose is to provide access to registry data via the REST API and the Asynchronous Messaging Subsystem, with the ability to write, read, modify, and delete data. The subsystem is also responsible for managing saved files, checking data integrity, and detecting unauthorized changes.

2. Subsystem functions

  • Create, read, modify and delete registry entries.

  • Search data by parameters.

  • Implementation of role-based access to data (RBAC).

  • Keeping track of changes.

  • Saving information about the origin of data.

  • Saving associated registry files.

  • Saving signed requests as grounds for changing registry data.

4. Subsystem components

Component name Representation in the register Source Repository Appointment

Service of synchronous management of registry data

registry-rest-api-deployment

origin

github:/epam/edp-ddm-service-generation-utility

github:/epam/edp-ddm-rest-api-core-base-image

github:/epam/edp-ddm-kafka-api-core-base-image

Processes of synchronous REST API requests to read and write registry data.

Asynchronous register data management service

registry-kafka-api-deployment

origin

Processes of asynchronous requests to read and write registry data.

Operational database of the registry

registry

origin

github:/epam/edp-ddm-registry-postgres

The database containing official service tables and all registry tables is modeled by the regulation administrator. It also captures the history of data changes and checks permissions according to RBAC.

Operational storage of digital registry documents

ceph:file-ceph-bucket

origin

-

Storage of digital registry documents

Input data storage

ceph:datafactory-ceph-bucket

origin

-

Storage of signed data when entered in the register.

Source data repository

ceph:response-ceph-bucket

origin

-

Temporary storage of data for transmission as part of interservice interaction within the subsystem

5. Technological stack

During the design and development of the subsystem, the following technologies were used:

6. Subsystem quality attributes

6.1. Scalability

The Registry Data Management Subsystem supports both horizontal and vertical scaling.

You can read more about scaling subsystems in the relevant sections:

6.2. Observability

The Registry Data Management Subsystem supports logging and collection of performance metrics for further analysis through the web interfaces of the corresponding Platform subsystems.

You can read more about the design of subsystems in the relevant sections:

6.3. Auditability

The Registry Data Management Subsystem captures significant technical and business events related to system operation by end users using audit event logging subsystem

6.4. Security

In the Registry data management subsystem, all requests to services that directly perform operations on registry data require authentication. The subsystem services are available only in the internal network of the registry.