Consolidate Common Module Microservices

[Varaniya201]

Title

Consolidate Common Module Microservices to Simplify Platform Architecture

---

1. Problem Statement (Mandatory)

The Common Module currently consists of multiple lightweight microservices that are deployed, managed, and maintained independently. This increases deployment complexity, operational overhead, infrastructure resource consumption, and maintenance effort.

To simplify the platform architecture, related services should be consolidated into logical deployable units while preserving existing functionality, API compatibility, and backward compatibility.

Purpose (Mandatory)

Consolidate Common Module microservices to:

• Reduce the number of deployable services.
• Simplify deployment and operational management.
• Reduce infrastructure resource consumption.
• Improve maintainability.
• Preserve existing functionality and API compatibility.

The proposed consolidation is as follows:

Existing Services	Consolidated Service
kernel-notification-service kernel-otpmanager-service kernel-auditmanager-service	kernel-notification-service
kernel-idgenerator-service kernel-salt-generator kernel-ridgenerator-service	kernel-idgenerator-service

Additionally:

• Remove kernel-pridgenerator-service from the platform.
• Retain kernel-config-server as an independent service without any changes.

Pre-Requisites (As Applicable)

• Existing service APIs and contracts are identified.
• Internal dependencies are migrated to the consolidated services.
• Deployment manifests, Helm charts, and CI/CD pipelines are updated.
• Existing consumers are identified to ensure backward compatibility.

2. Goals (Mandatory)

• Consolidate related Common Module services into logical deployable services.
• Reduce deployment complexity and infrastructure footprint.
• Preserve existing APIs and functionality.
• Eliminate redundant deployable services.
• Ensure existing integrations continue functioning without modification.

3. Out of Scope (Mandatory)

• Functional enhancements to Notification, OTP, Audit, ID Generation, RID Generation, or Salt Generation.
• Changes to existing API contracts.
• Changes to kernel-config-server.
• Introduction of new Common Module services.
• Functional changes to business logic.

4. Acceptance Criteria (Mandatory)

• Given the Common Module services are consolidated, when notification functionality is invoked, then all existing Notification APIs shall continue to function through kernel-notification-service.
• Given OTP functionality is required, when an OTP request is processed, then the functionality previously provided by kernel-otpmanager-service shall be available through kernel-notification-service.
• Given audit events are generated, when audit APIs are invoked, then the functionality previously provided by kernel-auditmanager-service shall be available through kernel-notification-service.
• Given ID generation is requested, when the request is processed, then ID generation functionality shall continue to be available through kernel-idgenerator-service.
• Given RID generation is requested, when the request is processed, then the functionality previously provided by kernel-ridgenerator-service shall be available through kernel-idgenerator-service.
• Given salt generation is requested, when the request is processed, then the functionality previously provided by kernel-salt-generator shall be available through kernel-idgenerator-service.
• Given the platform is deployed, when deployment artifacts are generated, then kernel-pridgenerator-service shall be removed from the codebase, deployment manifests, Helm charts, documentation, and configurations.
• Given the Common Module services are consolidated, when kernel-config-server is deployed, then it shall continue functioning independently without any functional or deployment changes.
• Given existing consumers invoke Common Module APIs, when the consolidated services are deployed, then no API breaking changes shall be introduced.
• Given regression and integration tests are executed, when the consolidated services are validated, then all existing functionality shall continue to work without regression.

Business Rules

• Given related services are consolidated, When requests are processed, Then the existing business logic shall remain unchanged.
• Given existing API contracts, When services are consolidated, Then backward compatibility shall be maintained.
• Given service consolidation, When deployments are performed, Then only the consolidated services shall be deployed.
• Given kernel-config-server is part of the Common Module, When service consolidation is implemented, Then no modifications shall be made to its functionality or deployment.

Exceptions & Error Handling

• Given service consolidation introduces dependency failures, When deployment validation is performed, Then deployment shall fail with appropriate error reporting.
• Given an internal service migration fails, When the consolidated service processes a request, Then existing error handling and logging mechanisms shall continue to function.
• Given an existing consumer invokes a Common Module API, When the request is processed, Then no consumer-facing errors shall occur due to service consolidation.

Basic Flow (As Applicable)

1. Deploy the consolidated Common Module services.
2. Route Notification, OTP, and Audit requests to kernel-notification-service.
3. Route ID Generation, RID Generation, and Salt Generation requests to kernel-idgenerator-service.
4. Remove kernel-pridgenerator-service from deployment.
5. Continue operating kernel-config-server independently.
6. Execute regression and integration testing to validate existing functionality.

Scenarios (As Applicable)

Scenario	Description
Notification Processing	Notification APIs are served by the consolidated Notification Service.
OTP Processing	OTP APIs are served by the consolidated Notification Service.
Audit Processing	Audit APIs are served by the consolidated Notification Service.
ID Generation	ID generation requests are served by the consolidated ID Generator Service.
RID Generation	RID generation requests are served by the consolidated ID Generator Service.
Salt Generation	Salt generation requests are served by the consolidated ID Generator Service.
Service Deployment	Platform deploys only the consolidated services.
Config Server	Config Server continues to function independently.

Data Fields (As Applicable)

Not Applicable

Non-Functional Requirements (As Applicable)

• Existing REST APIs shall remain backward compatible.
• Existing consumers shall require no changes.
• Existing deployment configurations shall be updated for the consolidated services.
• Infrastructure resource utilization should be be reduced.
• Existing monitoring, logging, metrics, and audit mechanisms shall continue to function.
• Existing regression and integration tests shall continue to pass.

Definition of Done (Mandatory)

• Technical design completed.
• Service consolidation implemented.
• kernel-pridgenerator-service removed.
• Deployment manifests updated.
• Helm charts updated.
• Configuration updated.
• Code implemented.
• Unit tests added.
• Integration tests added (if applicable).
• Existing tests passing.
• Documentation updated.
• Acceptance criteria validated.

5. References (Mandatory)

Documentation (As Applicable)

• Service Consolidation Design Document (To be created)

UI/UX Design Link (As Applicable)

Not Applicable

Git Discussion Link (As Applicable)

#1851

Related Issues / PRs (As Applicable)

Not Applicable