Service Discovery in Microservices: Client vs Server

TL;DR

Service discovery enables microservices to dynamically locate and communicate with each other without hardcoded network locations. Services register themselves with a central registry (like Consul or Eureka), and clients query this registry to find available instances. This pattern is essential for elastic, cloud-native architectures where service instances constantly scale up, down, or move across hosts.

Cheat Sheet:

• Client-side discovery: Client queries registry directly (Eureka, Consul)
• Server-side discovery: Load balancer queries registry (Kubernetes, AWS ELB)
• Health checks: Active (registry pings service) vs passive (service sends heartbeats)
• Registration: Self-registration (service registers itself) vs third-party (sidecar registers service)

The Problem It Solves

In traditional monolithic architectures, services had static IP addresses and ports that rarely changed. You could hardcode database.company.com:5432 in your configuration and sleep soundly. But modern distributed systems break this assumption completely.

Consider Netflix’s microservices architecture with thousands of service instances spinning up and down across multiple AWS regions. When a video streaming service needs to call the recommendation service, it faces several challenges: Which of the 200 recommendation service instances should it call? Are they all healthy? What if an instance crashes mid-request? What happens when autoscaling adds 50 new instances during peak hours?

Hardcoding service locations becomes impossible when instances are ephemeral. Configuration files can’t keep up with dynamic scaling. DNS caching causes stale routing for minutes after instances die. Load balancers need to know which backends exist. The fundamental problem is dynamic service location in elastic infrastructure where the network topology changes every few seconds.

Without service discovery, you’re forced into brittle solutions: static configuration files that break during deployments, manual load balancer updates that cause downtime, or custom scripts that poll cloud APIs and regenerate configs. Service discovery solves this by making service location a first-class runtime concern, not a deployment-time configuration problem.

Solution Overview

Service discovery introduces a service registry—a database of available service instances with their network locations, health status, and metadata. Think of it as a phone book that updates itself in real-time.

The pattern has two key workflows:

Registration: When a service instance starts, it registers itself with the registry, providing its IP address, port, and health check endpoint. The registry continuously monitors each instance’s health, removing dead instances within seconds. Services can self-register (the application code handles registration) or use third-party registration (a sidecar process like Registrator handles it).

Discovery: When a client needs to call a service, it queries the registry for available instances. The client receives a list of healthy endpoints, selects one (often using client-side load balancing), and makes the request. If the request fails, the client can immediately try another instance from the list.

The registry becomes the source of truth for “what services exist and where are they?” Popular implementations include Consul (HashiCorp), Eureka (Netflix), Etcd (CoreOS), and Kubernetes’ built-in service discovery. Each provides APIs for registration, querying, and health monitoring.

This pattern decouples service location from service identity. Clients depend on logical service names (“recommendation-service”) rather than physical addresses (“10.0.1.42:8080”). The registry handles the mapping, allowing infrastructure to change freely without breaking application code.

How It Works

Let’s walk through a complete service discovery lifecycle using a concrete example: an order service calling a payment service.

Step 1: Service Registration

When a payment service instance starts on host 10.0.1.42:8080, it registers with Consul:

{
  "Name": "payment-service",
  "ID": "payment-service-42",
  "Address": "10.0.1.42",
  "Port": 8080,
  "Tags": ["v2.1", "us-east-1"],
  "Check": {
    "HTTP": "http://10.0.1.42:8080/health",
    "Interval": "10s",
    "Timeout": "2s"
  }
}

Consul stores this registration and immediately begins health checking. Every 10 seconds, Consul sends an HTTP GET to /health. If the endpoint returns 200 OK, the instance stays in the registry. Three consecutive failures mark it unhealthy and remove it from query results.

Step 2: Client-Side Discovery

The order service needs to process a payment. Instead of hardcoded addresses, it queries Consul:

GET /v1/health/service/payment-service?passing

Consul returns all healthy payment service instances:

[
  {"ServiceID": "payment-service-42", "Address": "10.0.1.42", "Port": 8080},
  {"ServiceID": "payment-service-43", "Address": "10.0.1.43", "Port": 8080},
  {"ServiceID": "payment-service-44", "Address": "10.0.1.44", "Port": 8080}
]

The order service’s client library (like Netflix Ribbon) picks one instance using round-robin load balancing and makes the HTTP request. If the request fails, it immediately retries with a different instance from the list—no need to wait for DNS TTL expiration or load balancer health checks.

Step 3: Health Check Lifecycle

Suppose instance payment-service-43 crashes. Within 10 seconds, Consul’s next health check fails. After the configured failure threshold (typically 2-3 checks), Consul marks the instance as critical and stops returning it in queries. The order service’s next query gets only two instances. The failed instance is automatically removed from rotation without manual intervention.

When the payment service instance recovers or a new instance spins up, it re-registers and immediately becomes available once health checks pass.

Step 4: Server-Side Discovery Alternative

In Kubernetes, the flow differs. When you create a payment service deployment, Kubernetes automatically:

1. Creates a Service object with a stable DNS name: payment-service.default.svc.cluster.local
2. Maintains an Endpoints object listing all healthy pod IPs
3. Updates the Endpoints in real-time as pods start/stop
4. Configures kube-proxy to load balance requests to the service DNS name

The order service simply calls http://payment-service:8080/charge. Kubernetes DNS resolves this to the service’s cluster IP, and kube-proxy routes to a healthy pod. The application code never sees the registry—Kubernetes handles discovery transparently through DNS and iptables rules.

This server-side approach trades client control for operational simplicity. The client doesn’t choose instances or implement retry logic; the infrastructure handles it.

Client-Side Service Discovery Flow

graph LR
    Client["Order Service<br/><i>Client</i>"]
    Registry[("Consul Registry<br/><i>Service Catalog</i>")]
    P1["Payment Service<br/>Instance 1<br/>10.0.1.42:8080"]
    P2["Payment Service<br/>Instance 2<br/>10.0.1.43:8080"]
    P3["Payment Service<br/>Instance 3<br/>10.0.1.44:8080"]
    
    P1 -."0. Register + Health Check".-> Registry
    P2 -."0. Register + Health Check".-> Registry
    P3 -."0. Register + Health Check".-> Registry
    
    Client --"1. Query: GET /v1/health/service/payment-service?passing"--> Registry
    Registry --"2. Return healthy instances<br/>[42:8080, 43:8080, 44:8080]"--> Client
    Client --"3. Select instance (round-robin)<br/>4. POST /charge"--> P2
    P2 --"5. 200 OK"--> Client

In client-side discovery, the order service queries Consul directly to get a list of healthy payment service instances. The client then selects an instance using its own load balancing logic (round-robin, least connections, etc.) and makes the request. If the request fails, the client can immediately retry with a different instance from the cached list.

Service Registration and Health Check Lifecycle

sequenceDiagram
    participant PS as Payment Service<br/>Instance
    participant Consul as Consul Registry
    participant Client as Order Service<br/>Client
    
    Note over PS: Instance starts on<br/>10.0.1.42:8080
    PS->>Consul: 1. Register service<br/>{Name, Address, Port, Health Check URL}
    Consul->>Consul: 2. Store registration<br/>Start health monitoring
    
    loop Every 10 seconds
        Consul->>PS: 3. GET /health
        PS->>Consul: 4. 200 OK (healthy)
    end
    
    Client->>Consul: 5. Query payment-service instances
    Consul->>Client: 6. Return [10.0.1.42:8080, ...]
    Client->>PS: 7. POST /charge
    PS->>Client: 8. 200 OK
    
    Note over PS: Instance crashes
    Consul-xPS: 9. GET /health (timeout)
    Consul-xPS: 10. GET /health (timeout)
    Consul-xPS: 11. GET /health (timeout)
    Consul->>Consul: 12. Mark instance critical<br/>Remove from queries
    
    Client->>Consul: 13. Query payment-service instances
    Consul->>Client: 14. Return [other instances]<br/>(10.0.1.42 excluded)
    
    Note over PS: Instance recovers<br/>or new instance starts
    PS->>Consul: 15. Re-register service
    Consul->>PS: 16. GET /health
    PS->>Consul: 17. 200 OK
    Consul->>Consul: 18. Mark healthy<br/>Include in queries

The complete lifecycle shows registration, continuous health monitoring, and automatic removal of failed instances. Consul performs active health checks every 10 seconds. After three consecutive failures (configurable threshold), the instance is marked critical and excluded from discovery queries. When the instance recovers or a new one starts, it re-registers and becomes available once health checks pass.

Variants

Client-Side Discovery

The client queries the service registry directly and selects a target instance. Netflix Eureka and HashiCorp Consul use this pattern.

When to use: When you need fine-grained control over load balancing, retry logic, or routing decisions. Ideal for polyglot environments where different languages need consistent discovery.

Pros: Clients can implement sophisticated load balancing (least connections, latency-aware routing), cache registry responses for performance, and make routing decisions based on instance metadata (version tags, geographic location).

Cons: Every client must implement discovery logic, increasing complexity. Registry becomes a critical dependency—if Consul is down, services can’t discover each other. Clients must handle registry failures gracefully with caching and fallbacks.

Server-Side Discovery

A load balancer or router queries the registry and forwards requests. Kubernetes Services, AWS ELB with target groups, and NGINX Plus use this pattern.

When to use: When you want to keep client code simple and delegate infrastructure concerns to the platform. Perfect for organizations with strong platform teams.

Pros: Clients remain simple—just call a DNS name or VIP. The load balancer handles health checking, connection pooling, and retry logic. Easier to enforce organizational policies (rate limiting, circuit breaking) at the infrastructure layer.

Cons: Load balancer becomes a single point of failure and potential bottleneck. Less flexibility in routing decisions—clients can’t easily implement custom logic. Adds network hop latency.

DNS-Based Discovery

Services register DNS records (A or SRV records) instead of using a specialized registry. Consul supports DNS interface, and Kubernetes uses DNS heavily.

When to use: When you want maximum compatibility with existing tools and libraries that already understand DNS.

Pros: Universal compatibility—every language and framework has DNS support. No special client libraries needed. Simple mental model.

Cons: DNS caching causes stale data. TTLs must be very low (1-5 seconds) for dynamic environments, which increases DNS query load. SRV records provide port information but aren’t widely supported. A/AAAA records require clients to handle port separately.

Sidecar-Based Registration

A sidecar process (like Registrator or Consul Connect) handles registration instead of application code. The sidecar watches Docker events or monitors the application process.

When to use: When you want to decouple service discovery from application code, especially for legacy applications you can’t modify.

Pros: Application code stays clean—no registration logic. Works with any language or framework. Centralized registration logic is easier to update.

Cons: Additional process to deploy and monitor. Sidecar must reliably detect application health. Adds complexity to deployment manifests.

Server-Side Service Discovery with Kubernetes

graph TB
    subgraph Kubernetes Cluster
        Client["Order Service Pod<br/><i>Client Application</i>"]
        DNS["CoreDNS<br/><i>DNS Server</i>"]
        Service["Payment Service<br/><i>ClusterIP: 10.96.0.10</i>"]
        Endpoints["Endpoints Object<br/><i>Pod IP List</i>"]
        
        subgraph Payment Service Pods
            P1["Pod 1<br/>10.244.1.5:8080"]
            P2["Pod 2<br/>10.244.2.8:8080"]
            P3["Pod 3<br/>10.244.3.2:8080"]
        end
        
        KubeProxy["kube-proxy<br/><i>iptables rules</i>"]
    end
    
    Client --"1. Resolve payment-service.default.svc.cluster.local"--> DNS
    DNS --"2. Return ClusterIP: 10.96.0.10"--> Client
    Client --"3. POST http://10.96.0.10:8080/charge"--> Service
    Service -."Backed by".-> Endpoints
    Endpoints -."Tracks".-> P1 & P2 & P3
    Service --"4. Route via iptables"--> KubeProxy
    KubeProxy --"5. Forward to selected pod"--> P2
    P2 --"6. 200 OK"--> Client

In server-side discovery with Kubernetes, the client simply calls a stable DNS name. Kubernetes DNS resolves it to a ClusterIP, and kube-proxy (using iptables or IPVS) load balances the request to a healthy pod. The application code never interacts with the service registry—Kubernetes handles discovery transparently through DNS and network rules.

Trade-offs

Consistency vs Availability

Strong consistency (Consul, Etcd): Registry uses consensus protocols (Raft) to ensure all nodes agree on registered services. Writes are slower, and the registry becomes unavailable during network partitions affecting the quorum.

Eventual consistency (Eureka): Registry accepts writes immediately and replicates asynchronously. Clients might see stale data for seconds, but the registry stays available during partitions.

Decision criteria: Use strong consistency for critical infrastructure services where stale data causes cascading failures. Use eventual consistency for high-throughput user-facing services where temporary inconsistency is acceptable.

Client Complexity vs Infrastructure Complexity

Client-side discovery: Clients are complex (implement caching, load balancing, failover) but infrastructure is simple (just run the registry).

Server-side discovery: Clients are simple (just call a DNS name) but infrastructure is complex (deploy and scale load balancers, configure health checks).

Decision criteria: Choose client-side when you have strong client libraries and need custom routing logic. Choose server-side when you want to minimize client dependencies and have platform engineering resources.

Push vs Pull Health Checks

Active health checks (registry pings service): Registry controls check frequency and timeout. Detects failures quickly but generates constant traffic.

Passive health checks (service sends heartbeats): Service controls check timing. Lower network overhead but requires services to implement heartbeat logic. Failure detection is slower (must wait for missed heartbeats).

Decision criteria: Use active checks for critical services where fast failure detection justifies the overhead. Use passive checks for high-scale deployments where registry traffic becomes significant.

Registry Centralization

Single global registry: Simple to operate, single source of truth, but becomes a bottleneck and single point of failure.

Federated registries: Each region/datacenter has its own registry. Scales better and survives regional failures, but requires cross-region replication and conflict resolution.

Decision criteria: Start with a single registry cluster. Federate when registry query latency exceeds 10ms or when you need to survive regional outages.

Client-Side vs Server-Side Discovery Trade-offs

graph TB
    subgraph Client-Side Discovery
        C1["Complex Client<br/><i>Implements discovery logic</i>"]
        C2["Direct Registry Access<br/><i>Query Consul/Eureka</i>"]
        C3["Client-Side Load Balancing<br/><i>Round-robin, least connections</i>"]
        C4["Simple Infrastructure<br/><i>Just run registry cluster</i>"]
        
        C1 --> C2 --> C3 --> C4
    end
    
    subgraph Server-Side Discovery
        S1["Simple Client<br/><i>Just call DNS name</i>"]
        S2["Load Balancer Queries Registry<br/><i>LB maintains instance list</i>"]
        S3["Infrastructure Load Balancing<br/><i>HAProxy, NGINX, kube-proxy</i>"]
        S4["Complex Infrastructure<br/><i>Deploy and scale LBs</i>"]
        
        S1 --> S2 --> S3 --> S4
    end
    
    Decision{"Decision Criteria"}
    Decision -->|"Need custom routing logic<br/>Polyglot environment<br/>Fine-grained control"| C1
    Decision -->|"Minimize client dependencies<br/>Platform standardization<br/>Operational simplicity"| S1

The fundamental trade-off: client-side discovery pushes complexity to clients (they must implement discovery, caching, and load balancing) but keeps infrastructure simple. Server-side discovery keeps clients simple (just call a DNS name) but requires deploying and managing load balancers. Choose based on whether you have strong client libraries and need custom routing logic (client-side) or want to minimize client dependencies and standardize on platform infrastructure (server-side).

When to Use (and When Not To)

Use service discovery when:

Dynamic infrastructure is the norm: Your services scale automatically based on load, deploy multiple times per day, or run on spot instances that can disappear. If instance IP addresses change weekly or daily, service discovery is essential.

You have more than 5-10 microservices: Below this threshold, static configuration or DNS might suffice. Above it, manual coordination becomes error-prone. Airbnb adopted service discovery when they reached 100+ microservices and deployments became chaotic.

You need sub-second failover: When an instance crashes, you want clients to route around it immediately. DNS TTLs of 30-60 seconds are too slow. Service discovery with active health checks detects failures in 5-15 seconds.

Multi-region or hybrid cloud deployments: Services need to discover instances across AWS regions, on-premises datacenters, or multiple cloud providers. A unified registry provides a single discovery interface.

Avoid service discovery when:

You have a stable, small-scale deployment: If you run 3-5 services on fixed VMs that rarely change, the operational overhead of running Consul or Eureka outweighs the benefits. Use DNS or a simple load balancer.

Your platform provides it: If you’re all-in on Kubernetes, use its built-in service discovery rather than adding Consul. Don’t solve solved problems.

Network latency is critical: Every service discovery query adds 1-5ms of latency. For ultra-low-latency systems (high-frequency trading, real-time gaming), this overhead might be unacceptable. Consider caching aggressively or using static configuration.

You lack operational maturity: Running a highly available service registry requires expertise in distributed systems, monitoring, and incident response. If your team struggles with basic database operations, adding Consul will create more problems than it solves.

Real-World Examples

Netflix and Eureka

Netflix operates thousands of microservices across multiple AWS regions, with instances constantly autoscaling. They built Eureka, a client-side service discovery system optimized for availability over consistency. Each Eureka server maintains a full registry replica, and clients cache the registry locally. When a client needs to call a service, it uses its cached copy—no network call required. Clients refresh their cache every 30 seconds.

The interesting detail: Eureka prioritizes availability so aggressively that it enters “self-preservation mode” during network partitions. If 15% of instances fail to renew their heartbeats (indicating a network problem, not mass instance failure), Eureka stops expiring registrations. This prevents cascading failures where a network blip causes the registry to empty itself. The trade-off is temporary stale data, which Netflix considers acceptable for their use case.

Airbnb and SmartStack

Airbnb built SmartStack, combining Nerve (service registration) and Synapse (service discovery) with HAProxy. Each host runs Nerve, which monitors local service processes and registers them with Zookeeper. Each host also runs Synapse, which watches Zookeeper and dynamically reconfigures a local HAProxy instance.

The clever part: Services call localhost:3000 to reach the payment service. HAProxy on localhost forwards to a healthy remote instance. This gives server-side discovery benefits (simple client code) with client-side discovery performance (no central load balancer bottleneck). Each host’s HAProxy acts as a local load balancer with up-to-date service information.

Amazon and Internal Service Mesh

Amazon’s internal service infrastructure uses a proprietary service mesh with integrated discovery. Services register with a regional control plane, and each host runs an Envoy-like proxy. The proxy maintains a local cache of service endpoints and handles load balancing, retries, and circuit breaking.

What’s notable: Amazon’s system uses passive health checks exclusively. Services send heartbeats every 5 seconds. If three consecutive heartbeats are missed (15 seconds), the instance is removed. This design choice reduces load on the control plane—with millions of service instances, active health checks would generate enormous traffic. The trade-off is slightly slower failure detection, which Amazon considers acceptable given their redundancy levels.

Airbnb SmartStack Architecture

graph TB
    subgraph Host A
        App1["Payment Service<br/><i>Application Process</i>"]
        Nerve1["Nerve<br/><i>Registration Agent</i>"]
        Synapse1["Synapse<br/><i>Discovery Agent</i>"]
        HAProxy1["HAProxy<br/><i>localhost:3000</i>"]
    end
    
    subgraph Host B
        App2["Order Service<br/><i>Application Process</i>"]
        Synapse2["Synapse<br/><i>Discovery Agent</i>"]
        HAProxy2["HAProxy<br/><i>localhost:3000</i>"]
    end
    
    subgraph Host C
        App3["Payment Service<br/><i>Application Process</i>"]
        Nerve3["Nerve<br/><i>Registration Agent</i>"]
    end
    
    ZK[("Zookeeper<br/><i>Service Registry</i>")]
    
    Nerve1 -."1. Monitor local service<br/>Register if healthy".-> ZK
    Nerve3 -."1. Monitor local service<br/>Register if healthy".-> ZK
    
    ZK -."2. Watch for changes<br/>Get payment-service instances".-> Synapse1
    ZK -."2. Watch for changes<br/>Get payment-service instances".-> Synapse2
    
    Synapse1 --"3. Reconfigure HAProxy<br/>backend servers"--> HAProxy1
    Synapse2 --"3. Reconfigure HAProxy<br/>backend servers"--> HAProxy2
    
    App2 --"4. Call localhost:3000/charge<br/>(thinks it's local)"--> HAProxy2
    HAProxy2 --"5. Forward to healthy instance"--> App1
    App1 --"6. Process payment"--> App2

Airbnb’s SmartStack combines client-side and server-side discovery benefits. Nerve agents monitor local services and register them with Zookeeper. Synapse agents watch Zookeeper and dynamically reconfigure a local HAProxy instance on each host. Applications call localhost:3000, which HAProxy forwards to a healthy remote instance. This design provides server-side discovery simplicity (simple client code) with client-side discovery performance (no central load balancer bottleneck—each host has its own HAProxy).

---

Interview Essentials

Mid-Level

Explain the difference between client-side and server-side discovery with a concrete example. Describe how health checks work and why they’re necessary. Walk through what happens when a service instance crashes—how does the registry detect it, and how do clients learn about it? Be ready to discuss a specific tool like Consul or Kubernetes Services.

Example question: “Design service discovery for a microservices application with 20 services running on AWS. How would you handle service registration and discovery?”

Expected answer: Choose between client-side (Consul) or server-side (AWS ELB + target groups). Explain registration process, health check configuration (HTTP endpoint, check interval), and how clients query for services. Mention caching to reduce registry load and failover behavior when instances die.

Senior

Compare trade-offs between different discovery patterns and justify your choice for specific scenarios. Discuss failure modes: What happens when the registry is down? How do you handle split-brain scenarios in a distributed registry? Explain how service discovery integrates with load balancing, circuit breaking, and retry logic.

Example question: “Your service registry (Consul) becomes unavailable. How do you ensure services can still communicate?”

Expected answer: Client-side caching with TTLs (clients use stale data for 5-10 minutes). Fallback to DNS for critical services. Implement circuit breakers to prevent cascading failures. Discuss Consul’s gossip protocol for maintaining partial functionality during partitions. Mention monitoring and alerting to detect registry issues quickly.

Staff+

Design a multi-region service discovery system that survives regional failures. Discuss consistency models (strong vs eventual) and their implications for different service types. Explain how you’d migrate from one discovery system to another (e.g., Eureka to Kubernetes) with zero downtime. Address operational concerns: registry capacity planning, monitoring, and incident response.

Example question: “Design service discovery for a global application spanning 5 AWS regions with 10,000 service instances. How do you handle cross-region discovery and regional failover?”

Expected answer: Federated registries per region with selective cross-region replication. Services prefer local instances (latency) but can fail over to remote regions. Use DNS for cross-region discovery (slower but more reliable). Discuss data consistency challenges—eventual consistency is acceptable for most services, but critical infrastructure (authentication) might need strong consistency. Explain capacity planning: registry query load, storage requirements, and network bandwidth for replication.

Common Interview Questions

Why not just use DNS for service discovery? (Answer: DNS caching causes stale data, TTLs must be very low, no built-in health checking, limited metadata support)

How does service discovery work in Kubernetes? (Answer: Services create stable DNS names, Endpoints track pod IPs, kube-proxy handles load balancing)

What’s the difference between active and passive health checks? (Answer: Active = registry pings service, faster detection but more traffic; Passive = service sends heartbeats, lower overhead but slower detection)

How do you prevent the registry from becoming a single point of failure? (Answer: Run registry cluster with 3-5 nodes, client-side caching, fallback to DNS)

When would you choose client-side vs server-side discovery? (Answer: Client-side for custom routing logic and polyglot environments; server-side for operational simplicity and platform standardization)

Red Flags to Avoid

Not understanding the difference between service discovery and load balancing (they’re complementary—discovery finds instances, load balancing distributes requests)

Assuming DNS is sufficient for dynamic environments (DNS caching and TTLs make it unsuitable for rapid changes)

Ignoring health checks (without health checks, the registry routes traffic to dead instances)

Not considering registry availability (if the registry is down and clients have no cache, the entire system fails)

Overcomplicating simple scenarios (suggesting Consul for 3 services on fixed VMs is overkill)

---

Key Takeaways

Service discovery solves the dynamic service location problem in elastic infrastructure where instances constantly change. It decouples service identity (logical name) from service location (IP:port).

Client-side discovery (Eureka, Consul) gives clients control over routing and load balancing but increases client complexity. Server-side discovery (Kubernetes, load balancers) keeps clients simple but adds infrastructure complexity and a potential bottleneck.

Health checks are critical for registry accuracy. Active checks (registry pings service) detect failures faster but generate more traffic. Passive checks (service sends heartbeats) scale better but detect failures slower. Choose based on your failure detection requirements.

The service registry is a critical dependency. Implement client-side caching, fallback mechanisms (DNS), and run the registry as a highly available cluster. Plan for registry failures—they will happen.

Don’t build service discovery yourself unless you’re Netflix. Use proven tools: Consul for flexibility, Kubernetes Services for simplicity, or cloud-native options (AWS Cloud Map, Azure Service Fabric) for managed solutions.

---