Service Discovery — Algocraft System Design

🎮 What you can do

Click Scale Up to register a new instance, Scale Down to remove one
Click Kill Instance to simulate a crash
Switch between Client-Side and Server-Side discovery modes

👁 What to watch

Registry table updates instantly on register / deregister
Health check pulses every 2 s — failed instances turn red and are removed
Client routing adjusts automatically around downed instances

Discovery Mode

Service Types

Instances per Service

Actions

CLIENT

💻

Client App

Idle

SERVICE REGISTRY

📋 Service Registry
Consul / Eureka / etcd

Service	Instances	Health

SERVICE INSTANCES

Total Instances

Health Failures

Requests Routed

Avg Instances/Svc

Discovery Mode Comparison

When to Use

Any microservice system where instances scale dynamically — Kubernetes, ECS, EC2 Auto Scaling. Services must find each other without hardcoded IPs that change on every deploy or scaling event.

Trade-offs

The registry itself must be highly available (Consul cluster, etcd raft). Stale entries if health checks are slow — use short TTLs. Adds operational complexity: now you must manage the discovery infrastructure.

Interview Tip

"Kubernetes uses etcd as its service registry and kube-proxy for server-side discovery via ClusterIP Services. Consul is the go-to for non-K8s environments. Always ask: how does the client handle a stale entry that points to a dead instance?"