What is the Self Registration versus Third-Party Registration pattern for service discovery?

These two patterns describe how service instances get their network location recorded in (and removed from) the Service Registry — not how callers use it.

Self Registration — the service instance itself registers with the registry on startup and deregisters on orderly shutdown. It is also responsible for sending heartbeats so the registry can detect failed instances and remove stale entries.

• Example: A Spring Boot service with the Netflix Eureka client calls eurekaClient.register() at startup and eurekaClient.deregister() in a shutdown hook.
• Drawback: every service must import and configure the registry client library. The service is now coupled to the specific registry technology. If the registry changes, all services need updating.

Third-Party Registration — an external Registrar component monitors service instances (via the platform's event stream) and registers/deregisters them on their behalf. The service itself has zero registry awareness.

• Example (Kubernetes): The Endpoints controller watches pod events. When a pod passes its readiness probe, the controller adds its IP to the Endpoints resource for the corresponding Service. When the pod fails its probe or is deleted, the controller removes it. The pod never calls the registry directly.
• Example (Consul + Docker): A Registrator daemon on each host listens for Docker start/stop events and updates Consul accordingly.