Architecture
A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.
Full FlowZap Code
Client { # Client Service
n1: circle label:"Service Call Needed"
n2: rectangle label:"Query Service Registry"
n3: rectangle label:"Client-Side Load Balance"
n4: rectangle label:"Send Request to Instance"
n5: circle label:"Receive Response"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Registry.n6.handle(top) [label="Lookup"]
n3.handle(right) -> n4.handle(left)
n4.handle(bottom) -> Target.n12.handle(top) [label="HTTP/gRPC"]
}
Registry { # Service Registry (Consul/Eureka)
n6: rectangle label:"Receive Lookup Request"
n7: rectangle label:"Check Health Status"
n8: diamond label:"Healthy Instances?"
n9: rectangle label:"Return Instance List"
n10: rectangle label:"Return Service Unavailable"
n11: rectangle label:"Heartbeat Monitor"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Yes"]
n8.handle(bottom) -> n10.handle(top) [label="No"]
n9.handle(top) -> Client.n3.handle(bottom) [label="Endpoints"]
n10.handle(top) -> Client.n5.handle(bottom) [label="503"]
n11.handle(bottom) -> Target.n15.handle(top) [label="Ping"]
}
Target { # Target Service
n12: rectangle label:"Instance A (Primary)"
n13: rectangle label:"Instance B (Replica)"
n14: rectangle label:"Instance C (Replica)"
n15: rectangle label:"Register on Startup"
n16: rectangle label:"Deregister on Shutdown"
n12.handle(top) -> Client.n5.handle(bottom) [label="Response"]
n15.handle(top) -> Registry.n11.handle(bottom) [label="Heartbeat"]
n16.handle(top) -> Registry.n6.handle(bottom) [label="Remove"]
}
Why This Workflow?
Hardcoding service endpoints in configuration files breaks when instances scale up, fail, or move across hosts. Service discovery enables dynamic endpoint resolution, allowing microservices to find each other automatically as instances are added, removed, or replaced—essential for elastic cloud deployments.
How It Works
- Step 1: Each service instance registers itself with the service registry on startup.
- Step 2: The registry maintains a list of healthy instances with their network addresses.
- Step 3: Health check heartbeats verify instance availability at regular intervals.
- Step 4: When a service needs to call another, it queries the registry for available instances.
- Step 5: Client-side load balancing distributes requests across healthy instances.
- Step 6: Instances deregister on graceful shutdown to prevent routing to terminated processes.
Alternatives
DNS-based discovery is simpler but has TTL caching issues. Kubernetes built-in service discovery works within a cluster but not across clusters. Consul and Eureka provide cross-platform discovery. This template helps teams understand the discovery lifecycle.
Key Facts
| Template Name | Microservices Service Discovery Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A health check pattern architecture diagram with load balancer probes, deep health checks verifying database, cache, disk, and dependency status, automatic instance rotation, and alerting integration with PagerDuty for consecutive failures. This template models the health monitoring infrastructure that enables self-healing systems, where unhealthy instances are automatically removed from rotation and operations teams are alerted. Key for building production-ready services with proper observability.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.