HashiConf 2025 Don't miss the live stream of HashiConf Day 2 happening now View live stream
Well-Architected Framework

Deploy applications with traffic splitting for zero downtime

Application deployments with Consul service mesh provide fine-grained traffic control, automatic health checking, and deep observability that traditional load balancers cannot match. Service mesh architectures use service splitters to dynamically route traffic between application versions, enabling gradual rollouts, instant rollback, and comprehensive monitoring of deployment health.

Service splitters gradually shift traffic from old versions to new versions while monitoring health and performance metrics. This approach combines the benefits of canary and blue/green strategies to test changes with production traffic while maintaining the ability to rollback instantly if issues occur.

Why use service mesh for traffic splitting

Using service mesh for traffic splitting addresses the following operational challenges:

  • Enable fine-grained traffic control: Load balancers provide basic traffic distribution, but service meshes offer percentage-based traffic splitting at the service level, request-level routing, and dynamic traffic shifting based on real-time metrics. Service mesh gives you precise control over which requests go to which version.

  • Improve observability and monitoring: Service mesh provides automatic metrics collection, distributed tracing, and service health data, allowing you to detect issues immediately and make informed rollback decisions.

  • Automate service discovery and health checking: Service mesh automatically discovers services, monitors health continuously, and removes unhealthy instances from traffic rotation without manual intervention.

  • Reduce blast radius with progressive rollouts: Deploying to all users simultaneously increases the impact of malfunctions, in case of issues or bugs. Service mesh enables progressive traffic shifting, allowing you to validate each stage before proceeding and limiting the impact of deployment issues to a small user subset.

When to use service mesh vs load balancers

Choose your traffic splitting approach based on application architecture and operational requirements.

Use service mesh when you need:

  • Fine-grained traffic control with percentage-based splits
  • Observability into service-to-service communication
  • Automatic service discovery and health checking
  • Complex routing rules based on headers, paths, or other criteria
  • Distributed tracing across microservices

Use load balancers when you need:

  • Simple traffic distribution without service-to-service visibility
  • Lower operational complexity and fewer components to manage
  • Traditional infrastructure without containerized microservices
  • Basic health checks and traffic routing

Service mesh adds operational complexity and requires understanding of service mesh concepts. Use it when the benefits like observability, fine-grained control, and automatic service discovery justify the additional complexity.

Implement traffic splitting with Consul

Consul service mesh provides traffic splitting through service splitter configurations. Service splitters define how traffic distributes between different service instances, allowing you to gradually shift traffic from old versions to new versions while monitoring health metrics.

The following example shows a Consul service splitter configuration for canary deployment:

# Service defaults for web application
Kind = "service-defaults"
Name = "web"
Protocol = "http"

# Service resolver defining service subsets
Kind = "service-resolver"
Name = "web"

Subsets = {
  v1 = {
    Filter = "Service.Meta.version == 1"
  }
  v2 = {
    Filter = "Service.Meta.version == 2"
  }
}

# Service splitter for traffic distribution
Kind = "service-splitter"
Name = "web"

Splits = [
  {
    Weight        = 90
    ServiceSubset = "v1"
  },
  {
    Weight        = 10
    ServiceSubset = "v2"
  },
]

The Consul service splitter routes 90% of traffic to version 1 (stable) and 10% to version 2 (canary). To gradually shift traffic, update the weights and apply the changes. Consul immediately adjusts traffic distribution without downtime.

Use the following steps to implement zero-downtime deployments with Consul:

  1. Register services: Register blue and green service versions with Consul, including version metadata in service tags.
  2. Configure health checks: Define health check endpoints that Consul monitors continuously.
  3. Deploy new version: Deploy the green version and verify it passes Consul health checks.
  4. Configure service splitter: Create service splitter with initial traffic split (for example, 90% blue, 10% green).
  5. Monitor metrics: Use Consul proxy metrics to track error rates, latency, and throughput for both versions.
  6. Adjust traffic gradually: Update splitter weights to shift more traffic to green (50/50, then 0/100).
  7. Complete rollout or rollback: Either remove blue version after green is stable, or adjust splitter back to 100% blue if issues occur.

Consul proxy metrics provide detailed health and performance information including upstream/downstream network traffic, request details, error rates, and performance metrics. This observability enables you to detect issues immediately and make informed decisions about proceeding with rollout or rolling back.

Amazon EKS and Azure Kubernetes Service support Consul service mesh, allowing you to observe traffic within your service mesh, understand service interactions, and debug traffic issues effectively.

To learn how to implement service splitters for canary deployments, follow the seamless canary deployments with service splitters tutorial.

HashiCorp resources:

Consul service mesh tutorials:

Next steps

In this section of Zero-downtime deployments, you learned how to use Consul service mesh for traffic splitting with progressive rollouts and observability. Zero-downtime deployments are part of the Define and automate processes pillar.

Refer to the following documents to learn more about deployment strategies:

Edit this page on GitHub