Skip to main content
Version: 12.10.0

Detailed Architecture Overview

The Architecture is built on top of the core Spring framework. It is a simplified and automated version of the spring framework. The spring boot follows a layered architecture in which each layer communicates to other layers(Above or below in hierarchical order).

This document describes of the solution architecture, including major components and their interactions, processes, and data. It's a Scalable Platform designed for multi-tenant in the client eco system and can accommodate a flexible number of functions or Tenants and Open for the third-party cooperation and collaboration, where the features can be integrated through a plugin system

Alt text

Thirdparty System​

There are various surrounding systems involved in Backend Architecture to interact and evaluate the activities which are mentioned below:

  1. OGS - for Authentication and Authorization
  2. Almeda - for Video Consultation appointment booking and tracking.
  3. Docyet
  4. Thryve
  5. Mindhsine
  6. Queo
  7. Yuble
  8. WonderPush

Multitenancy​

System is designed in such a way to handle multiple AOK can be enrolled. New schema to be created for AOK to be onboarded and necessary config related changes will ensure the launch of new AOKs wihtout any Major code changes or implementations.

2 different approach on Multitenncy is possible.

  1. Shared Compute In Shared compute model, the multi tenancy is achieved by sharinf the computing infrastucture. Means regardless of the tenant , the API requests will reach to the same backend cluster. In the multi tenancy model of spring boot applications, a schema per tenant model is implemented and activated based on the X-TENANTID header specified in the API requests
  2. Dedicated Compute In the Dedicated model , the computing instance will be sperated for the tenant. the Kong gateway and the Kafka clusters will be still shared between tenants , but the API requests will be routed to the seperate tenants based on the request headers from the API gateway itself.

Alt text

Backend Services​

Below are the list of services currently available to serve as per the requirements.

  1. Authentication Service
  2. Queo Service.
  3. Docyet
  4. Consent Management
  5. Consent Support Tool
  6. Challenge Support Tool
  7. Doctor Search
  8. Megazine
  9. yuble
  10. Symptom Check
  11. Video Consultation
  12. User Profile
  13. User Common Service
  14. User Account Deletion Service
  15. Sports Challenge
  16. Mental Challenge
  17. Motivation
  18. User Compass
  19. Content Service
  20. Bonus Service
  21. Notification Service
  22. Challenge DS
  23. Cron Job

OGS Login​

  1. The stability of the login in connection with the session and token management is optimally implemented by connecting with OGS OAuth Broker. Navida Pro is not maintaining the credentials and session maintenace.
  2. Biometric authentication is also enabled.

Challenges​

  1. This is the complex part of the Navida Pro app which connects with various third party systems like Thryve, Mindshine and Komoot to validate and pull the required data for this module.

Data Store Service​

  1. This is one common service where all other services to connect in order to persist data to Database. As per agreed architecture standards, direct persistance of data from respective service is not allowed. Hence data-store-service is one stop solution to push the data.
  2. Two options are available to push the data to database in data-store-service. Data-Store-Implementation and Kafka-Implementation.
  3. Data-Store-Implementation is the direct process to push the data into database.
  4. Kafka-Implementation is the process to push the data into database through Kafka Implementation. This is the must implemented process before delivering the code from DEV to Higher environments. Control is enabled to ensure the code will work with Kafka-Implementation mode only.