Data Center Health Registry, Haversine Distance and Nearest-Healthy Routing

Build a small in-memory service that sends each client to a nearby data center. The exercise has three parts, each building on the previous one, and is meant to be finished in about an hour. It is closer to a math problem than to an algorithms problem: most of the risk lies in getting the distance calculation and the corner cases exactly right.

Constraints and Clarifications

• Assume each data center has a unique identifier and a location given as latitude and longitude in decimal degrees.
• All state lives in memory, and nothing needs to be persisted.

Clarifying Questions

• Are operations called as methods on a class, or delivered as a list of commands whose printed output is compared with expected text?
• Are coordinates guaranteed to be valid, or should invalid ones be rejected?
• How should numeric outputs, such as distances, be formatted and rounded?

Part 1 — Data center registration and health state management

Support registering a data center with its identifier and location, updating its health state, and reading its current health state.

Clarifying Questions for this Part

• Which health states exist: only healthy and unhealthy, or more?
• Is a newly registered data center healthy by default, or unhealthy until its first health report?
• What should happen when an identifier is registered twice?

What This Part Should Cover

• A data model keyed by identifier that holds the location and the current health state
• Validation of identifiers, coordinates and state values
• Defined behavior for duplicate registrations and unknown identifiers

Part 2 — Computing the haversine distance

Implement a function that returns the great-circle distance between two points on the Earth, each given as latitude and longitude in degrees, using the haversine formula.

Clarifying Questions for this Part

• Which Earth radius and which unit, kilometers or miles, does the expected output use?

What This Part Should Cover

• The haversine formula with the correct conversion from degrees to radians
• Numerical robustness for identical and nearly antipodal points
• Correct behavior across the 180th meridian and near the poles

Part 3 — Proximity-based routing

Given a client's latitude and longitude, return the identifier of the nearest data center that is currently healthy, measured with the distance from Part 2.

Clarifying Questions for this Part

• How should exact distance ties be broken?
• What should be returned when no data center is healthy?
• Is a single data center expected, or a ranked list that allows failover?

What This Part Should Cover

• Filtering by health state before choosing by distance
• Deterministic tie-breaking and an explicit result when nothing is routable
• The cost per request and how it grows with the number of data centers