# Grab's service mesh evolution: From Consul to Istio

[Grab](https://yomu.fyi/company/grab) · Hilman Kurniawan · Jul 16, 2025

## Summary

Grab operated over 1,000 microservices across hybrid infrastructure using Consul alongside a fallback mechanism called Catcher. Single-point-of-failure vulnerabilities in Consul servers and limited support for multi-cluster operations prompted an evaluation of alternative mesh technologies, ultimately leading to the selection of Istio. Grab avoided the standard single-control-plane-per-cluster pattern by deploying multiple external control planes in dedicated Kubernetes clusters arranged in active-active pairs. Migration began in Q4 2024, shifting traffic across AWS and GCP while handling both HTTP and gRPC protocols with gradual traffic-shifting and rollback mechanisms.

## Takeaways

- Grab's legacy Consul setup relied on a fallback mechanism called Catcher, which added complexity and hindered advanced circuit breaking and retry policies.
- Instead of running a control plane inside each cluster, Grab deployed multiple control planes on dedicated Kubernetes clusters in active-active pairs for isolation and high availability.
- The Istio migration began in Q4 2024 with a GCP-to-AWS cross-cloud transition alongside parallel initiatives to migrate HTTP and gRPC traffic across meshes without downtime.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [gRPC](https://yomu.fyi/topic/grpc), [Kubernetes](https://yomu.fyi/topic/kubernetes), [Microservices](https://yomu.fyi/topic/microservices), [Migrations](https://yomu.fyi/topic/migration)

[Read original post](https://engineering.grab.com/service-mesh-evolution)