A Government Portal Rewrite: Language and Build Choices Under Procurement Rules
A ministry's citizen-services portal is being rewritten. The existing system is a 12-year-old PHP monolith with no automated tests. Requirements: support 60 simultaneous caseworkers, integrate with a national identity API over mutual TLS, run on the government's on-premise Linux estate, and be maintainable by a team of six who currently know Java and JavaScript only. Procurement rules require at least three competing bids and a 10-year support horizon. A vendor proposes rewriting in a niche functional language with a small local talent pool, arguing it reduces defect rates. Another proposes keeping PHP and adding tests incrementally.
1. Evaluate the two proposals against the stated constraints.
Read the worked answer
Niche functional language. Defect reduction is a plausible but unquantified claim. Against it: the team of six cannot maintain it without retraining; the 10-year support horizon and small talent pool create recruitment and continuity risk; procurement for three bids in a niche stack is harder. The 60-user load is modest and does not require exotic concurrency. This proposal optimises an unmeasured benefit while creating measurable maintainability risk.
Incremental PHP with tests. Preserves working behaviour, builds a test safety net, and matches existing skills. But it leaves a 12-year-old monolith in place and may not address structural problems.
Judgement. Neither is fully satisfactory. The strongest answer identifies a third path: rewrite in Java (team skill, on-premise fit, 10-year support, large hiring pool) with a strangler-fig migration, adding automated tests around each extracted module. This satisfies procurement, skills, and longevity simultaneously. Simply picking one vendor proposal without noting the third option is a weaker answer.
2. The identity API uses mutual TLS. What design and testing implications follow?
Read the worked answer
Mutual TLS means both client and server present certificates, so the portal must manage a client certificate, its private key, and trust anchors - and rotate them before expiry. This is an operational obligation across the 10-year horizon, not a one-off configuration.
Design implications. Certificate and key storage must be secured (not in source control); expiry monitoring and rotation runbooks are required; the integration must fail closed if the handshake fails, with a clear caseworker-facing error rather than a silent hang. The on-premise estate must permit outbound TLS to the identity service, which may require firewall change requests.
Testing implications. Automated tests need a stub identity service with its own test certificates, plus at least one environment exercising real mutual TLS. Certificate expiry should be tested deliberately (a short-lived test cert) so the team sees the failure mode before production. These points are specific to mTLS and show the candidate has reasoned about the constraint rather than restating it.