High level architecture
Last updated
Last updated
The functionalities and purpose of various microservices built as part of Sunbird-RC are explained below.
This is the core service which enables the major functionalities of SunbirdRC. It exposes API that can be used to configure schemas and manage entities and workflows. It can also process creating entities synchronously or asynchronously. The registry is enabled to support various database providers, which are:
Graph database (Neo4J)
Relational databases (Postgresql, HSQLDB, H2, MariaDB, MySQL, MSSQLServer)
NoSQL databases (Cassandra)
The registry generates REST APIs for the schemas that are created dynamically. It also applies authentication and authorization on schema APIs based on the schema configuration. The registry service also provides discovery API, which can be used to search public data of a particular schema. Elasticsearch needs to be configured to the registry to enable the discovery of schemas.
This service needs to be enabled if attestation/workflows are required. This service is responsible for handling all the claims of an attestation.
This service needs to be enabled if verifiable credentials need to be generated for a schema. This service is capable of generating W3C based schemas. This service support configuring multi keys based on issuer. The service supports RSA & ED25519 based keys. The key file needs to be mounted to the service.
This service needs to be enabled if a visual template for the verifiable credentials is required. This service is capable of generating a QR based template. The templates that are supported are SVG/HTML/PDF.
This service is required to send SMS or emails to the users. This service is used by the registry to send invite notifications to users. It is also used by keycloak to send OTP messages. This service can be configured with 3rd party plugins to send notifications.
This service is used to expose public keys that are used to generate verifiable credentials. It has APIs that exposes all the public keys or issuer-based public key. This API will be used by the verification services to verify the issued verifiable credentials.
This service is used to handle all the events emitted by registry through kafka. The service stores this events in clickhouse. However the service can be used to connect different databases. Service also exposes an API which returns all the events emitted
Clickhouse is a open source database. We are using clickhouse to store all the events that are emitted in this clickhouse
This service will be used by verifying clients to proxy the context URLs that are used in the verifiable credentials. The public facing verifying clients needs to access the content of the context URLs that are present in the verifiable credentials. If the client is UI based application, the context URLs will be blocked due to CORS issues. This service can be used to overcome the CORS issue. The context URLs can be routed to this service which can proxy and return back the contents.
The registry requires a main DB that is used as the main store for storing all data. The following DB providers can be used:
Graph database (Neo4J)
Relational databases (Postgresql, HSQLDB, H2, MariaDB, MySQL, MSSQLServer)
NoSQL databases (Cassandra)
Elastic search is used to store all public data and it enables the discovery of data.
Keycloak is used to enable authentication and authorization of the users on using the APIs.
The SunbirdRC package is also shipped with a custom modified Nginx image which is configured with all the reverse proxies for the services and also contains a generic verification page.
S3 compatible object storage service is also shipped along with services which can be used to store files. It can be used by adopters who are running the services on private/bare metal servers.
The registry core service will require a Redis cache layer when the core service is scaled to multiple instances.
Kafka service is required to create entities in an asynchronous fashion. If the system needs to handle high load and high availability the entity creation(with generating credentials) can be processed asynchronously using Kafka.
Bulk issuance service will allow the issuers to upload their csv files and issue credentials to all those actors present in each row of a csv. The service also has the capability to return a file based reports which will download a csv file which will contain a column of errors that occurred for a that specific actors data
