Service Discovery & Config Management
Master client-side vs server-side service discovery, service registries (Consul, etcd, Eureka), configuration management (ConfigMap, HashiCorp Vault, AWS Parameter Store), feature flags, and Blue-Green and Canary deployment strategies.
Master client-side vs server-side service discovery, service registries (Consul, etcd, Eureka), configuration management (ConfigMap, HashiCorp Vault, AWS Parameter Store), feature flags, and Blue-Green and Canary deployment strategies. This hands-on tutorial focuses on practical implementation of service discovery & config management concepts.
Service Discovery & Configuration Management
In a microservices architecture, service instances come and go constantly — Kubernetes scales them up and down, deployments create new instances, failures cause restarts. Service discovery is how services find each other dynamically without hardcoded IP addresses.
[!IMPORTANT] Never hardcode IP addresses or service hostnames in your application code. Use a service registry or Kubernetes DNS for service discovery. Hardcoded addresses break every time a service is restarted, scaled, or deployed to a new host.
Service Discovery Patterns
Configuration Management
Blue-Green & Canary Deployments
Quiz
Quiz
Question 1 of 2Your Order Service needs to call User Service. You have 5 instances of User Service running at different IPs. What is the correct way to discover User Service instances?
Key Takeaways
✅ Never hardcode service IPs — use a service registry or Kubernetes DNS for dynamic discovery.
✅ Client-side discovery = service queries registry and load balances itself (Netflix pattern).
✅ Server-side discovery = DNS/load balancer handles routing (Kubernetes pattern — preferred).
✅ Secrets must go in Vault/Secrets Manager — never in environment files, source code, or ConfigMaps.
✅ Feature flags decouple deployment from release — enable features for 1% of users, monitor, then ramp.
✅ Canary = gradual percentage rollout with auto-rollback. Blue-Green = full environment swap with instant rollback.
Client-Side vs Server-Side Discovery Comparison
| Aspect | Client-Side Discovery | Server-Side Discovery |
|---|---|---|
| Who queries registry? | Client directly | Load balancer / router |
| Client complexity | High (client handles retry, LB logic) | Low (client calls one endpoint) |
| Infrastructure needed | Service registry only | Service registry + load balancer |
| Flexibility | High (client picks algorithm) | Lower (LB decides) |
| Examples | Eureka (client), Consul (client mode) | AWS ALB, Kubernetes Service |
| Failure mode | Client must handle registry unavailability | LB handles it |
Official Resources
- 📖 HashiCorp Consul — Service discovery and configuration
- 📖 HashiCorp Vault — Secrets management
- 📖 AWS Secrets Manager — Managed secrets on AWS
- 📖 LaunchDarkly Feature Flags — Feature flag platform
What's Next?
Services can discover and talk to each other — but how do you ensure only authenticated users access your APIs?
Next: Authentication & Authorization — JWT, OAuth 2.0, SSO, and how to secure your APIs at scale.