Service Mesh Architecture: A Decision Framework for When Complexity Pays Off

Your team just deployed the fifteenth microservice, and suddenly debugging a single user request feels like archaeology. Traces disappear between services, retry storms cascade unpredictably, and nobody can explain why latency spikes every Tuesday at 3 PM. The Jaeger dashboard shows a request entered the order service, but somewhere between there and the inventory check, it vanished into what your team has started calling “the void.”

You’ve done everything right. Structured logging, correlation IDs propagated through headers, metrics exported to Prometheus. Your observability stack would make any platform team proud. Yet when the VP of Engineering asks why checkout failures tripled last night, you spend four hours correlating timestamps across six different dashboards before discovering that a single misconfigured connection pool in a service three hops downstream was silently dropping requests under load.

This is the moment when someone inevitably mentions Istio. Or Linkerd. Or whatever service mesh their previous company adopted. The promise sounds compelling: automatic mTLS, standardized retries, circuit breaking, and observability that actually shows what’s happening on the wire. The reality is more nuanced. A service mesh adds operational complexity, increases resource consumption, and introduces a new failure domain that your on-call engineers need to understand at 3 AM.

The question isn’t whether service meshes work—they do, remarkably well for the right problems. The question is whether your organization has crossed the complexity threshold where a service mesh pays for itself, or whether you’re about to trade one set of debugging nightmares for another.

That threshold lives in the gap between what your applications can observe and what’s actually happening on the network.

The Observability Gap That Service Meshes Actually Solve

You’ve instrumented your services with OpenTelemetry. Your distributed traces flow into Jaeger or Tempo. Your metrics populate Grafana dashboards with request latencies, error rates, and throughput. Yet production incidents still blindside you—services degrade mysteriously, latency spikes appear without corresponding application errors, and your post-mortems repeatedly identify “network issues” without actionable details.

This gap exists because your observability stack watches your application code, not the infrastructure layer between services.

The Invisible Network Layer

When Service A calls Service B, your application-level tracing captures the request leaving A and arriving at B. What happens in between remains opaque:

• DNS resolution delays
• Connection establishment and TLS handshake timing
• Load balancer queuing and routing decisions
• TCP retransmissions and packet loss
• Connection pool behavior at both ends

Your application logs show a 200ms latency spike, but the actual breakdown—50ms in connection pool wait, 80ms in TLS negotiation, 70ms in actual processing—stays invisible. You’re debugging symptoms without seeing causes.

Load balancers compound this problem. When requests route through an ALB or NGINX ingress, your traces show calls to a single endpoint. You lose visibility into which backend instance handled the request, whether the load balancer retried failed attempts, and how connection reuse patterns affected performance.

Failure Modes That Surface Too Late

Three reliability problems consistently escape application-level monitoring:

Connection pool exhaustion happens silently. Your HTTP client maintains a pool of connections to downstream services. When the pool fills—perhaps because a downstream service slowed down—new requests queue internally before your application code even executes. Timeouts occur, but your traces show them as slow downstream calls rather than local resource exhaustion.

Retry amplification creates cascading failures. Service A retries failed calls to Service B. Service B, under load, retries its calls to Service C. Without coordination, a single slow response triggers exponential retry storms. Application-level retry logic operates in isolation, unaware of the broader retry behavior across the request path.

Circuit breaker gaps leave vulnerable windows. You’ve implemented circuit breakers in your application code, but they track success rates per logical service. When Service B runs across ten instances and only two are failing, your circuit breaker sees an 80% success rate and stays closed. Meanwhile, 20% of your users experience consistent failures.

💡 Pro Tip: Before adopting a service mesh, audit how many production incidents in the past year traced back to network-layer behavior your current tooling couldn’t observe. If that number is zero, simpler solutions likely suffice.

Service meshes address these gaps by inserting an infrastructure-level proxy (the sidecar) into every service’s network path. This proxy sees every connection, every retry, every timeout—and reports on all of it uniformly.

Understanding this architectural pattern—how sidecars, control planes, and data planes work together—is essential before evaluating whether your organization needs one.

Anatomy of a Service Mesh: Sidecars, Control Planes, and Data Planes

Understanding service mesh architecture requires clarity on three distinct layers: the sidecar proxies that handle traffic, the control plane that orchestrates them, and the data plane they collectively form. Each layer introduces operational complexity that must be weighed against the problems it solves.

The Sidecar Pattern: Transparent Traffic Interception

Every service mesh deployment injects a proxy container alongside your application container. This sidecar—typically Envoy in Istio and Cilium, or linkerd2-proxy in Linkerd—intercepts all inbound and outbound network traffic through iptables rules or eBPF hooks. Your application code remains unchanged; it sends requests to localhost or standard service endpoints while the sidecar handles the actual network communication.

This transparency comes with a cost. The sidecar must parse every packet, apply policies, collect metrics, and forward traffic. For a typical request, this adds 2-5ms of latency in Istio deployments, while Linkerd’s purpose-built Rust proxy achieves sub-millisecond overhead in most scenarios.

Control Plane: The Mesh Brain

The control plane serves three critical functions:

Configuration distribution pushes routing rules, retry policies, and traffic splits to every sidecar in real-time. When you deploy a canary release, the control plane propagates updated routing weights to thousands of proxies within seconds.

Certificate management handles mTLS at scale. The control plane acts as a certificate authority, issuing short-lived certificates to each sidecar and rotating them automatically. This eliminates the operational burden of managing TLS certificates across hundreds of services.

Policy enforcement translates high-level security rules into proxy configurations. Define that service A can only communicate with service B, and the control plane generates the corresponding authorization policies for every relevant sidecar.

Data Plane Overhead: Real Resource Costs

Each sidecar consumes memory and CPU that would otherwise serve your application. Baseline resource consumption varies significantly:

Linkerd sidecars typically require 10-20MB of memory and minimal CPU at idle. Istio’s Envoy sidecars start at 50-100MB and scale with traffic volume. For a cluster running 500 pods, this translates to 5-50GB of additional memory consumption across the mesh.

💡 Pro Tip: Profile your actual traffic patterns before sizing sidecar resources. High-throughput services processing thousands of requests per second require significantly more sidecar resources than low-traffic batch processors.

Architectural Approaches: Istio vs. Linkerd vs. Cilium

Istio offers the most feature-rich control plane with extensive traffic management, security policies, and observability. This flexibility demands operational investment—expect dedicated engineering time for upgrades and troubleshooting.

Linkerd prioritizes simplicity and performance. Its control plane is smaller, upgrades are straightforward, and the Rust-based proxy delivers lower latency. The tradeoff is fewer advanced traffic management features.

Cilium takes a fundamentally different approach by leveraging eBPF to handle mesh functionality within the Linux kernel. This eliminates sidecar containers entirely for many use cases, reducing resource overhead but requiring kernel version 5.10 or later and eBPF expertise.

Your choice depends on existing team expertise, performance requirements, and the specific mesh capabilities you need. Before committing to any implementation, you need a clear framework for determining whether your organization has crossed the complexity threshold where service mesh investment pays off.

The Complexity Threshold: When Service Meshes Make Sense

Service meshes solve real problems, but they introduce operational overhead that demands organizational readiness. Before evaluating specific platforms, you need to honestly assess whether your team and infrastructure have crossed the threshold where mesh benefits outweigh costs.

Team Size and Operational Maturity

A service mesh requires dedicated attention. At minimum, you need two to three engineers who can own the mesh infrastructure—handling upgrades, debugging proxy issues, and tuning configuration. Organizations with a single SRE juggling everything from CI/CD to incident response will find a mesh becomes another neglected system generating alerts.

Beyond headcount, operational maturity matters. Your team should already have:

• Established observability practices: If you lack centralized logging and basic metrics aggregation, a mesh’s telemetry flood will overwhelm rather than enlighten.
• Deployment automation: Manual deployments and service mesh sidecars create dangerous friction. GitOps or equivalent automation is a prerequisite.
• Incident response processes: Mesh failures cascade. Teams without runbooks and on-call rotations will struggle to diagnose whether issues originate in application code, the sidecar proxy, or the control plane.

The 20-Service Inflection Point

Service mesh benefits compound nonlinearly. With 5 services, you have 20 potential service-to-service communication paths. At 20 services, that number reaches 380. At 50 services, it explodes to 2,450.

This combinatorial growth explains why organizations crossing the 15-20 service threshold consistently report that mesh adoption pays off. Below this threshold, the operational overhead of maintaining the mesh infrastructure often exceeds the cost of implementing cross-cutting concerns per-service.

💡 Pro Tip: Count services that actively communicate, not total deployments. A dozen batch jobs sharing a database don’t create the network complexity that justifies a mesh.

When Libraries Beat Infrastructure

Library-based solutions like Resilience4j (Java), Polly (.NET), or custom middleware handle circuit breaking, retries, and timeouts without infrastructure complexity. Choose libraries over meshes when:

• Your services share a primary language runtime
• You have fewer than 15 actively communicating services
• Your team has deep expertise in that language ecosystem
• You’re primarily solving resilience rather than security or observability

Red Flags You’re Not Ready

Pause your mesh evaluation if you recognize these patterns:

• Monolith-in-disguise: Services that always deploy together or share databases don’t benefit from mesh traffic management
• No existing observability baseline: You won’t measure mesh value without comparison data
• Unstable Kubernetes foundation: Mesh debugging requires confident cluster operations skills

With these criteria established, organizations ready for adoption face the critical first step: implementing mTLS to establish the zero-trust foundation that enables everything else.

Implementing mTLS and Zero-Trust Networking

Traditional perimeter security assumes everything inside your network is trustworthy—an assumption that crumbles when a single compromised service can pivot laterally across your entire microservices fleet. Service meshes flip this model by treating every service-to-service connection as potentially hostile, requiring cryptographic proof of identity for every request. This zero-trust approach ensures that authentication and authorization happen at every hop, not just at the network edge.

Automatic mTLS: Encryption Without the Certificate Headache

Istio’s sidecar proxies handle TLS certificate issuance, rotation, and validation automatically. Each workload receives a short-lived X.509 certificate from the mesh’s certificate authority (istiod), eliminating the operational burden of managing certificates across hundreds of services. This automation removes one of the primary barriers to adopting encryption everywhere—the complexity of PKI operations at scale.

When you deploy a service into an Istio-enabled namespace, the sidecar proxy:

1. Requests a certificate from istiod using a secure token provisioned via Kubernetes service account credentials
2. Receives a SPIFFE-compliant identity in the format spiffe://cluster.local/ns/payments/sa/payment-processor
3. Automatically rotates certificates before expiration (default: 24 hours)
4. Terminates and originates TLS for all mesh traffic

This happens transparently—your application code makes plain HTTP calls while the sidecars encrypt everything in transit. The short certificate lifetime limits the window of exposure if a certificate is somehow compromised, while automatic rotation ensures services never experience certificate expiration outages.

Enforcing Strict mTLS with PeerAuthentication

By default, Istio operates in permissive mode, accepting both plaintext and mTLS connections. This flexibility aids migration but provides no security guarantees. For zero-trust enforcement, configure strict mode:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

This policy rejects any connection that cannot present a valid mesh certificate. Apply it namespace-by-namespace during migration, or mesh-wide by deploying to the istio-system namespace. You can also target specific workloads using label selectors, enabling gradual rollout within a namespace.

💡 Pro Tip: Before enabling STRICT mode, verify all services in the namespace have sidecars injected. Services without sidecars cannot originate mTLS connections and will fail immediately. Use istioctl analyze to detect these gaps proactively.

Fine-Grained Access Control with AuthorizationPolicy

mTLS authenticates identity; AuthorizationPolicy determines what that identity can access. Together, they implement the zero-trust principle of “never trust, always verify” at the service level. This policy restricts the order service to receive traffic only from the API gateway and inventory service:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: order-service-access
  namespace: production
spec:
  selector:
    matchLabels:
      app: order-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
          - "cluster.local/ns/production/sa/api-gateway"
          - "cluster.local/ns/production/sa/inventory-service"
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/v1/orders/*"]

The principals field references SPIFFE identities, binding authorization to cryptographic identities rather than network addresses. Even if an attacker compromises the payment service and pivots to the order service’s IP, they cannot forge the inventory service’s identity. This identity-based approach remains effective even in dynamic environments where IP addresses change frequently due to scaling events or pod restarts.

Debugging Certificate and Identity Issues

When mTLS connections fail, start with the proxy’s certificate chain:

istioctl proxy-config secret deploy/order-service -n production

This displays the workload’s current certificate, including expiration time and SPIFFE identity. For connection-level debugging:

istioctl proxy-config log deploy/order-service --level debug
kubectl logs deploy/order-service -c istio-proxy | grep -i "tls\|certificate\|spiffe"

Common failure patterns include clock skew between nodes (certificates appear expired), service accounts missing from AuthorizationPolicy principals, and namespace isolation preventing istiod from issuing certificates. Network policies blocking communication with istiod on port 15012 can also prevent certificate provisioning entirely.

The istioctl analyze command catches many configuration errors before they cause production incidents:

istioctl analyze -n production

This static analysis identifies misconfigurations such as AuthorizationPolicies referencing non-existent service accounts, PeerAuthentication policies without corresponding DestinationRules, and services lacking sidecar injection that would break under strict mTLS.

Zero-trust networking eliminates an entire category of lateral movement attacks, but security is only one dimension of service mesh value. The same traffic interception that enables mTLS also unlocks sophisticated traffic management patterns—canary deployments, circuit breakers, and fault injection—that reduce blast radius when things go wrong.

Traffic Management Patterns That Reduce Blast Radius

A single failing service can cascade through your entire system in milliseconds. Without traffic management policies, one slow database connection or memory leak propagates failures upstream, turning a localized issue into a platform-wide outage. Service meshes intercept this cascade at the network layer, giving you production-ready resilience patterns without touching application code.

Circuit Breakers with Outlier Detection

Circuit breakers prevent requests from reaching unhealthy endpoints. Istio’s outlier detection automatically ejects failing pods from the load balancing pool based on consecutive errors or response times. Unlike application-level circuit breakers that require library integration and per-service configuration, mesh-level circuit breakers apply consistently across your entire fleet with a single policy.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-service
  namespace: checkout
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 50
        http2MaxRequests: 200
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 50
      minHealthPercent: 30

This configuration ejects any pod that returns three consecutive 5xx errors. The baseEjectionTime increases exponentially with each ejection, and maxEjectionPercent ensures at least half your pods remain in rotation even during widespread failures. The minHealthPercent threshold of 30% disables outlier detection entirely if too few healthy hosts remain—preventing the circuit breaker from making a bad situation worse by ejecting your last healthy instances.

Retry Budgets That Prevent Cascade Failures

Naive retry logic amplifies failures exponentially. If every service retries three times, a single failed request at depth four in your call graph generates 81 downstream requests. This retry storm overwhelms already struggling services and transforms recoverable failures into complete outages. Service meshes solve this with retry budgets that limit total retry attempts across the request path.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: inventory-service
  namespace: catalog
spec:
  hosts:
    - inventory-service
  http:
    - route:
        - destination:
            host: inventory-service
      retries:
        attempts: 2
        perTryTimeout: 3s
        retryOn: connect-failure,refused-stream,unavailable,cancelled,retriable-4xx
      timeout: 10s

💡 Pro Tip: Set perTryTimeout lower than your overall timeout divided by attempts. This example allows two retries at 3 seconds each within a 10-second total budget, leaving headroom for connection overhead.

The retryOn conditions matter. Retrying on 5xx errors sounds reasonable until a downstream service returns 500 because it’s overloaded—retries make that worse. Limit retries to transient failures like connection resets and explicitly retriable status codes. The retriable-4xx condition specifically targets 409 Conflict responses, which often indicate temporary state conflicts that resolve on retry.

Canary Deployments with Automatic Rollback

Weighted routing shifts traffic gradually to new versions while monitoring error rates. Combined with Flagger or Argo Rollouts, the mesh automatically rolls back when metrics degrade. This approach limits the blast radius of bad deployments to a small percentage of traffic, catching issues before they affect your entire user base.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
  namespace: orders
spec:
  hosts:
    - order-service
  http:
    - match:
        - headers:
            x-canary-user:
              exact: "true"
      route:
        - destination:
            host: order-service
            subset: canary
    - route:
        - destination:
            host: order-service
            subset: stable
          weight: 90
        - destination:
            host: order-service
            subset: canary
          weight: 10

This configuration routes 10% of production traffic to the canary while allowing internal testers to opt-in via header. Progressive delivery controllers increment the canary weight automatically when success rate and latency metrics remain within thresholds. If the canary’s error rate exceeds baseline by more than a configured threshold, traffic shifts back to stable within seconds—far faster than human-initiated rollbacks.

Rate Limiting: Mesh Layer vs Application Layer

Application-layer rate limiting requires every service to implement and coordinate limits, leading to inconsistent enforcement and duplicated logic. Mesh-layer rate limiting enforces global policies at the proxy level, protecting services before requests reach application code.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: global-ratelimit
  namespace: istio-system
spec:
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: http_local_rate_limiter
              token_bucket:
                max_tokens: 1000
                tokens_per_fill: 100
                fill_interval: 1s

Mesh-layer rate limiting protects services from traffic spikes regardless of client behavior. When a misbehaving client or sudden traffic surge threatens to overwhelm a service, the proxy rejects excess requests with 429 status codes before they consume application resources. Application-layer rate limiting remains necessary for business logic like per-user quotas or API tier enforcement. Use both: mesh limits as a safety net protecting infrastructure, application limits for policy enforcement and business rules.

These traffic policies generate rich telemetry about failure modes and traffic patterns. The next section examines how to transform that telemetry into actionable observability through distributed traces and service dependency maps.

Observability: From Distributed Traces to Service Dependency Maps

A service mesh transforms observability from a fragmented collection of language-specific instrumentation into a unified telemetry layer. When every service-to-service call passes through a sidecar proxy, you gain consistent metrics, traces, and logs regardless of whether your services run on Go, Python, Java, or Rust.

Unified Telemetry from Sidecar Proxies

Envoy sidecars automatically capture the four golden signals—latency, traffic, errors, and saturation—at the network layer. This instrumentation requires zero code changes. A Python service with no OpenTelemetry SDK and a heavily instrumented Java service produce identical metric formats, enabling apples-to-apples comparisons across your entire fleet.

The mesh generates distributed traces by propagating context headers (like x-request-id and x-b3-traceid) through every hop. Even services that don’t participate in tracing become visible nodes in your trace spans, eliminating the blind spots that plague partially-instrumented architectures.

Integrating with Your Observability Stack

Istio exposes Prometheus metrics out of the box. Configure your Prometheus instance to scrape the mesh’s telemetry endpoint:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: istio-mesh-metrics
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: istiod
  endpoints:
    - port: http-monitoring
      interval: 15s
      path: /metrics
  namespaceSelector:
    matchNames:
      - istio-system

For distributed tracing, configure Istio to export spans to Jaeger:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: mesh-tracing
  namespace: istio-system
spec:
  tracing:
    - providers:
        - name: jaeger
      randomSamplingPercentage: 10.0
      customTags:
        environment:
          literal:
            value: production
        cluster:
          literal:
            value: us-east-1-primary

💡 Pro Tip: Start with a 1-5% sampling rate in production. You can increase sampling for specific services during incident investigation using namespace-scoped Telemetry resources.

Service Topology with Kiali

Kiali transforms raw telemetry into actionable topology maps. It visualizes real-time traffic flow between services, highlights error rates with color-coded edges, and surfaces configuration issues like missing mTLS or misconfigured virtual services.

The service graph view reveals dependencies that documentation misses. When the checkout service suddenly shows elevated latency, Kiali’s graph immediately shows whether the bottleneck originates from the payment gateway, inventory service, or database connection pool—without grep-ing through logs.

Golden Signals Dashboards for SLO Tracking

Build Grafana dashboards around the metrics that matter for your SLOs. Istio’s standard metrics provide everything you need:

• Latency: istio_request_duration_milliseconds_bucket for p50/p95/p99 histograms
• Traffic: istio_requests_total for request rates by service and response code
• Errors: Filter istio_requests_total where response_code matches 5xx patterns
• Saturation: Correlate with Envoy’s envoy_server_memory_allocated and connection pool metrics

The real power emerges when you combine mesh telemetry with SLO-based alerting. Instead of alerting on arbitrary thresholds, alert when your error budget burn rate exceeds sustainable levels—a signal that actually demands human attention.

This observability foundation does more than accelerate incident response. It provides the data you need for confident traffic management decisions—the same data that enables the incremental rollout strategy we’ll examine next.

Adoption Strategy: Incremental Rollout Without Big Bang Migration

The fastest path to service mesh failure is attempting a weekend cutover. Organizations that succeed treat mesh adoption as a progressive capability rollout, building confidence and operational muscle at each stage before expanding scope.

Start with Observability Before Enforcement

Deploy your mesh in permissive mode first. Inject sidecars configured to observe and report without enforcing mTLS or traffic policies. This approach delivers immediate value through distributed tracing and service dependency visualization while carrying zero risk of breaking existing communication patterns.

Run in observability-only mode for two to four weeks. During this period, you’ll discover service communication patterns that weren’t documented, identify services making unexpected cross-namespace calls, and establish baseline latency and throughput metrics. This reconnaissance phase pays for itself by preventing enforcement-mode surprises.

Namespace-by-Namespace Rollout

Resist the urge to mesh your entire cluster simultaneously. Select an initial namespace based on three criteria: the team owning it has bandwidth for the experiment, the services within it have comprehensive integration tests, and the blast radius of any issues remains contained.

After proving success in your pilot namespace, expand methodically. Each new namespace should go through the same observability-then-enforcement progression. Document the rollout runbook after your first namespace and refine it with each subsequent addition.

💡 Pro Tip: Start with a namespace containing internal tools or non-critical workloads. Your CI/CD pipeline’s supporting services make excellent initial candidates—they exercise real traffic patterns without customer-facing risk.

Handling Legacy Services

Not every service can run sidecars. JVM applications with aggressive heap configurations, services with strict latency SLAs, or legacy workloads running on outdated base images may require exclusion from the mesh.

For these services, configure explicit mesh bypass rules. Most mesh implementations support annotation-based exclusion at the pod or namespace level. Create a registry of excluded services with documented justification—this prevents the exclusion list from becoming a dumping ground for teams avoiding adoption.

Establishing Performance Baselines

Measure everything before injecting the first sidecar. Capture P50, P95, and P99 latency for inter-service calls, document CPU and memory consumption per pod, and record baseline throughput under typical load.

After mesh adoption, repeat these measurements under equivalent conditions. Expect 2-5ms of additional latency per hop from sidecar proxying. If you observe significantly higher overhead, investigate proxy resource limits and connection pooling configuration before assuming the mesh itself is the problem.

With your rollout strategy defined, you have a complete framework for evaluating and adopting service mesh infrastructure in a way that matches your organization’s operational maturity.

Key Takeaways

• Evaluate service mesh adoption using the complexity threshold: 20+ services, dedicated platform team, and existing observability foundation are prerequisites for successful deployment
• Start with observability-only mode in a single namespace to measure latency overhead and validate operational readiness before enabling mTLS enforcement
• Configure circuit breakers with outlier detection and retry budgets together—either alone creates different failure modes that mesh policies are designed to prevent
• Use AuthorizationPolicy deny-by-default patterns to implement zero-trust, then explicitly allow required service-to-service communication paths