Revoke and decommission PRID and RID generation (consolidate to AID)

[Varaniya201]

Story statement

As a MOSIP platform operator, I want to revoke and decommission the now-unused PRID and RID generation services — fully superseded by AID, with all consumers already migrated — so that ID generation runs as a single AID service, reducing infrastructure, code and maintenance overhead, while AID's own API contract stays unchanged.

Description

AID (Application ID) is now the unified identifier across the application lifecycle, and all consumers that previously used PRID (pre-registration) and RID (registration) have already been migrated to AID. The PRID and RID generators are therefore fully redundant with no active callers.

Because there are no remaining consumers, this is a direct decommission rather than a staged deprecation: a one-time verification confirms zero live PRID/RID traffic, after which their endpoints are revoked and the services and their backing resources are removed. AID remains as the sole ID-generation service, and its generation logic and API contract are untouched. This supersedes the earlier plan to co-locate three generators in one or two pods — instead, two of the three are removed outright.

As-Is

• PRID, AID and RID exist as separate ID-generation services, each with its own pod(s), database/ID pool and replenishment scheduler.
• AID has already replaced PRID and RID functionally, and all consuming flows (pre-registration, registration, partner integrations) have been migrated to AID.
• PRID and RID generators have no active callers but still run, consuming infrastructure and carrying maintenance cost.

To-Be

• AID is the single ID-generation service, running in its existing/one pod.
• PRID and RID generation endpoints are revoked and their services removed from deployment.
• PRID and RID databases, ID pools and schedulers are decommissioned per the agreed data-retention/archival policy.
• AID's API contract remains unchanged; the overall ID-generator pod and resource footprint drops.

Goals

• Remove the redundant PRID and RID generator services to reduce infrastructure, pod count, code and maintenance surface.
• Consolidate ID generation to AID only.
• Keep AID's API contract (paths, payloads, status codes, headers, error formats) completely unchanged.
• Decommission cleanly, with a final verification that no consumer is affected.

Non-Goals

• No change to AID's generation logic, format, uniqueness rules or API contract.
• Not introducing a new ID type — AID already exists and is in use.
• No re-migration work, since consumers are already on AID.
• No migration of historical PRID/RID records beyond the agreed archival/retention policy.
• Not redesigning AID into a monolith with other modules.

Acceptance Criteria

1. A final code/configuration audit and live-traffic check confirm zero active PRID/RID generation calls across all modules and partner integrations before removal.
2. PRID and RID generation endpoints are revoked and their services removed from deployment.
3. AID generation endpoints — request/response payloads, status codes, headers and error formats — remain byte-for-byte unchanged, and AID continues to operate normally.
4. Total ID-generator pod count and aggregate resource reservation are reduced by removing the PRID and RID deployments (captured as a before/after comparison).
5. PRID and RID databases, ID pools and replenishment schedulers are decommissioned per the data-retention/archival policy, with no orphaned schedulers left running.
6. All configuration, Helm charts and service URLs referencing PRID/RID generation are removed or cleaned up, and no module fails to start due to a missing PRID/RID generator dependency.
7. Regression suites pass: pre-registration and registration flows complete end-to-end using AID with no functional regression.
8. A rollback plan exists to restore PRID/RID generation in the unlikely event a hidden dependency surfaces post-removal.
9. Documentation is updated to reflect AID as the single ID generator and the removal of PRID and RID.