RESW

The Problem

RESW's predecessor was a desktop enrolment application installed on every officer's machine nationwide. Every change (a bug fix, a new validation rule, a compliance update mandated by NIMC) meant building a new release and getting it installed on every single machine before it took effect. There was no reliable way to confirm which version any given center was even running, which made enforcing compliance across the network practically impossible. Moving to a web application meant NIMC could ship a change once, centrally, and have every enrolment center running it immediately, without chasing installs across the country.

Constraints

• ▹Moving to the browser solved the update problem, but a browser can't talk to locally connected fingerprint scanners and cameras the way a desktop app could, so capturing biometrics now needs a plugin, not just browser APIs.
• ▹Enrolment data is sensitive: needs encryption at rest and in transit, not just HTTPS in front.
• ▹Supports 7 distinct enrolment types (new, modification, renewal, replacement, death notice, split across adult and child records), each with different validation rules.
• ▹Has to integrate with other NIMS backend components without becoming tightly coupled to any one of them.
• ▹Biometric and demographic capture has to meet international identity standards: World Bank ID4D guidelines (one of the major drivers of identity-ecosystem standards globally), ICAO photo-quality requirements, and liveness-detection compliance to catch spoofed captures.
• ▹Enrolment records also have to sync out to legacy state-level infrastructure that only speaks SOAP/XML, across every state concurrently, without records clashing or duplicating.

How It Was Solved

• ▹Paired the Angular web frontend with a lightweight, windowless Java plugin that runs locally on the officer's Windows machine, bridging the browser to connected fingerprint and capture devices.
• ▹A Spring Boot integrator service syncs enrolment data with other NIMS components over a Kafka-backed event store (topic-based), instead of point-to-point integration with every downstream system.
• ▹Legacy state-infrastructure sync runs over SOAP/XML across multiple concurrent instances; ShedLock coordinates the scheduled sync jobs across those instances so the same job never runs twice at once.
• ▹Each enrolment gets a unique tracking ID generated with a standards-based prefix scheme to avoid collisions across concurrent instances, the exact scheme is client-proprietary, so that's as deep as I can go on it.
• ▹AES for data at rest, RSA for data in transit, and SHA-512 for integrity hashing, between the frontend, core API, and other NIMS systems.
• ▹Integrates with CBS to verify Remita payments by RRR (Remita Retrieval Reference) before an enrolment can proceed, instead of taking payment status on faith.