🟢 Junior Level

Service Discovery — це механізм, який дозволяє сервісам знаходити один одного у динамічному середовищі, де IP-адреси постійно змінюються.

У контейнеризованому середовищі (Docker, Kubernetes) поди і контейнери створюються і знищуються динамічно. Кожен новий контейнер отримує новий IP. Хардкодити адреси неможливо.

Проблема: У мікросервісах сервіси запускаються і зупиняються (особливо в Kubernetes). IP-адреса змінюється щоразу. Як сервісу A знайти сервіс B?

Рішення: Service Discovery — як “телефонна книга” для сервісів.

Сервіс A → Service Discovery: "Де сервіс B?"
Service Discovery → Сервіс A: "Сервіс B на 10.0.0.5:8080"
Сервіс A → 10.0.0.5:8080 → Сервіс B

---

🟡 Middle Level

Типи Service Discovery

1. Client-side discovery:

Сервіс A → Service Registry → отримує IP → викликає Сервіс B

2. Server-side discovery:

Сервіс A → Load Balancer → Service Registry → Сервіс B

Компоненти

Service Registry:

Зберігає список сервісів і їхніх адрес
Приклади: Consul, Eureka, ZooKeeper, etcd

Service Registration:

Сервіс при старті реєструється в Registry
При зупинці — deregister

Типові помилки

1. Stale entries: ``` Сервіс впав, але не встиг deregister Registry все ще віддає старий IP Рішення: health checks + TTL

TTL (Time-To-Live) — запис у реєстрі «протухає» через N секунд. Якщо сервіс не оновив запис вчасно — він видаляється автоматично.

---

### Коли Service Discovery НЕ потрібен

- **2-3 сервіси** зі статичними IP — простіше DNS
- **Моноліт на шляху до мікросервісів** — поки немає динамічного масштабування
- **Single-server deployment** — все на одній машині

---

## 🔴 Senior Level

### Архітектурні Trade-offs

| Client-side                    | Server-side         |
| ------------------------------ | ------------------- |
| Більше контролю                | Простіше для клієнтів  |
| Потрібно реалізувати балансировку | LB бере на себе    |
| Залежність від Registry client | Незалежні клієнти |

### Production Experience

**Kubernetes:**

K8s має вбудований Service Discovery:

• Service → DNS name
• kube-proxy → load balancing
• Endpoints → список Pod IP

Сервіс A → my-service.default.svc.cluster.local → kube-proxy → Pod B

### Best Practices

✅ Health checks для кожного сервісу ✅ TTL для entries ✅ Client-side caching з expiry ✅ Graceful shutdown → deregister

❌ Без health checks ❌ Довгий TTL (stale data) ❌ Без fallback при недоступності Registry ```

---

🎯 Шпаргалка для співбесіди

Обов’язково знати:

• Service Discovery — “телефонна книга” для мікросервісів у динамічному середовищі
• Два типи: client-side (клієнт сам шукає) і server-side (LB шукає)
• Service Registry зберігає список сервісів і їхніх адрес (Consul, Eureka, etcd)
• Health checks + TTL вирішують проблему stale entries
• У Kubernetes вбудований: Service → DNS name → kube-proxy → Pod
• Graceful shutdown → deregister з Registry
• НЕ потрібен для 2-3 сервісів зі статичними IP

Часті уточнюючі питання:

• Що таке stale entries? Сервіс впав, але запис у Registry ще живий — рішення: health checks + TTL.
• Client-side vs server-side? Client-side = більше контролю, server-side = простіше для клієнтів.
• Навіщо TTL? Запис «протухає» через N секунд, якщо сервіс не оновив — видаляється автоматично.
• K8s Service Discovery як працює? Service → DNS name → kube-proxy → Endpoints (список Pod IP).

Червоні прапорці (НЕ говорити):

• “Service Discovery потрібен завжди” — ні, для 2-3 сервісів вистачить DNS
• “TTL не важливий, сервіси стабільні” — у контейнеризованому середовищі IP змінюються постійно
• “Client-side не потрібен, тільки server-side” — Netflix Ribbon, Spring Cloud LoadBalancer
• “Registry = single point of failure, значить не потрібен” — потрібен fallback і кластеризація

Пов’язані теми:

• [[8. У чому різниця між client-side та server-side discovery]]
• [[9. Що таке API Gateway і які завдання він вирішує]]
• [[12. Як реалізувати горизонтальне масштабування мікросервісів]]
• [[26. Які інструменти використовуються для оркестрації мікросервісів]]
• [[15. Як організувати комунікацію між мікросервісами]]