How the interviewer opens it
“Design a system that registers service instances and lets clients discover healthy endpoints. Instances start, fail, and move while clients continue to send requests.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Deployment and record count
- Clients
- Read and write traffic
- Registration lifetime and health
- Latency and failure bounds
- Consistency and availability
- Durability
- Endpoints and moves
- Access control
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Register and remove service instances
- Track application readiness and registration lifetime
- Return endpoint sets and deliver client updates
- Handle process replacement and registry faults
Usually out of scope
- Discover services across regions
- Provide a DNS interface
- Build a proxy for application traffic
- Move all instances in one atomic operation
What interviewers ask about
- Endpoint health and registration lifetime
- A missing heartbeat can mean a failed instance or a network fault. Registry reachability does not prove that an instance can serve application requests.
- Client update delivery
- A client needs a complete endpoint view while instances change. Slow clients and popular services can cost more than the registry state.
- Instance identity and moves
- An address can identify different processes over time. Requests from an old process must not change its replacement.
- Registry behavior during partitions
- Clients need endpoints during registry faults. A reachable server can still hold an old view or lack authority to confirm it.
Common mistakes
- Place a registry query on every application request.
- Treat a heartbeat as proof that every client can reach the application.
- Ignore the gap between an initial endpoint list and later updates.
- Use an address as the complete identity of an instance.
- Return cached data without a limit on its age.
- Partition the registry before estimating its small record set and large subscriber load.
The bar by level
- Mid-level (L4/E4)
- Defines the API and instance records. Handles readiness, heartbeat expiry, and process removal. Keeps registry calls outside application requests.
- Senior (L5/E5)
- Connects snapshots to later updates without gaps. Rejects stale process requests. Handles bounded client queues, quorum loss, and the 60-second freshness limit.
- Staff (L6+/E6+)
- Quantifies fanout and reconnect pressure. Defines renewal acknowledgment and expiry behavior across leader changes. Plans capacity limits and safe client upgrades. If the interviewer adds the second-region requirement, defines each region's authority.