Choosing a Delivery Model for a Land Records Service
A land ministry wants a citizen-facing service to check mutation (land transfer) application status. Volumes: about 30,000 checks per day, peaking at 200 requests per second during announcement periods. The service must show status only, never personal data beyond a masked application number. The ministry has a small in-house team of four developers, a data centre with two aging servers, and a policy that citizen data must remain within the country. A vendor proposes a public cloud region abroad with autoscaling and a 99.95% uptime SLA at low cost. An alternative is to host on the two aging servers behind the ministry's existing firewall. A third option is a national government cloud located in-country, with slower provisioning and a higher price.
1. Evaluate the three options against the stated constraints.
Read the worked answer
The foreign public cloud is cheapest and most elastic, but violates the data-locality policy - even masked status data derived from citizen records may be covered. It should be excluded unless the policy is formally changed, which is not the team's call. The two aging servers are in-country and already owned, but two servers cannot reliably handle 200 requests per second without load balancing, and there is no redundancy: one failure means outage. The in-country government cloud satisfies the locality policy and offers elasticity, but slower provisioning conflicts with the announcement-peak requirement if capacity is requested late. The defensible choice is the government cloud, with capacity reserved ahead of known announcement dates and a caching layer to absorb peaks.
2. How would you design the service to meet the 200 requests-per-second peak with a four-person team?
Read the worked answer
Keep the architecture simple. Put a read-only status API behind a cache: status records change rarely, so cache responses for 60 seconds keyed by application number. Use a content delivery or reverse-proxy cache in front so repeated checks never reach the database. Rate-limit per IP to blunt scraping. The database should be read-replica or a materialised view of the workflow system, not the live transactional database, so citizen checks cannot slow officers. Queue or shed load beyond capacity with a clear 'try again' page rather than failing silently. For a four-person team, managed services (managed database, managed cache) reduce operational burden. Load-test to 300 requests per second before each announcement.
3. What governance and monitoring arrangements should accompany the launch?
Read the worked answer
Define an SLA with the government cloud provider covering availability and support response, and a fallback plan if the provider fails. Publish a privacy notice explaining what is shown and logged. Log access for audit but avoid storing full application numbers in logs where possible. Set up monitoring for error rate, latency and cache hit ratio, with alerts to the team. Establish a change advisory process so the small team does not deploy untested changes before peak periods. Agree a data-sharing protocol with the workflow system owner. Finally, schedule a post-launch review after the first announcement peak to decide whether reserved capacity was correctly sized.