SYSTEM Cited by 3 sources
Envoy¶
Envoy is an open-source L7 proxy originally developed at Lyft, now a CNCF graduated project. It's the canonical data-plane component of sidecar-based service meshes (Istio, Consul Connect, AWS App Mesh) and a common ingress/edge proxy in its own right. Envoy's dynamic configuration API — xDS — has become the de facto standard interface between control planes and L7 proxies, and is now used beyond sidecars as a general service-discovery contract.
Minimum viable definition for this wiki; expand on future ingests.
Core features relevant to system design¶
- L7 load balancing. Per-request decisions (vs. per-connection at L4); required for HTTP/2, gRPC, and other long-lived-connection protocols.
- xDS-driven dynamic configuration. Control planes stream cluster / endpoint / route / listener updates without reloads.
- Health-aware routing. Outlier detection, active health checks, priority levels for failover.
- Advanced load-balancing algorithms. Round-robin, random, least-request, ring hash, Maglev, weighted — and Power of Two Choices on
least_request. - Observability. Per-request metrics, access logs, tracing hooks.
Roles in distributed architectures¶
- Sidecar-mesh data plane (Istio, Consul): one Envoy per pod, intercepts all service traffic.
- Ingress / edge proxy: single Envoy tier at the cluster edge; frequent pattern for HTTP/gRPC gateway.
- Standalone L7 LB: Envoy as a modern replacement for HAProxy / NGINX when dynamic topology matters.
Seen in¶
- sources/2025-10-01-databricks-intelligent-kubernetes-load-balancing — Databricks uses Envoy as its ingress gateway, configured via the same EDS control plane that feeds internal Armeria clients. This gives internal and external traffic a single source of truth for endpoint topology. The post also discusses Envoy-as-sidecar (Istio/Ambient Mesh) as the evaluated-and-rejected alternative for intra-cluster routing.
- sources/2024-10-28-dropbox-robinhood-in-house-load-balancing — Dropbox's Robinhood LBS writes PID-computed endpoint weights into a ZooKeeper/etcd routing DB; Envoy clients consume them natively via EDS and do weighted round-robin per request. Same one-control-plane-many-data-planes pattern as Databricks, but applied to PID-driven weights rather than topology-only EDS.
- sources/2025-01-18-aws-app-mesh-discontinuation-service-connect-migration — Envoy is the data plane for both AWS App Mesh (customer-managed sidecar) and ECS Service Connect (AWS-managed sidecar). Same proxy, different operational contract — canonical write-up of the managed sidecar tradeoff vs customer-run Envoy. App Mesh exposes the full Envoy config surface (retry/outlier tuning, mTLS, version-weighted routing); Service Connect narrows to timeouts-only in exchange for AWS-managed lifecycle + free CloudWatch metrics.
Related¶
- concepts/xds-protocol
- concepts/layer-7-load-balancing
- patterns/proxyless-service-mesh — the alternative-to-sidecars architecture
- patterns/managed-sidecar — AWS-managed vs customer-managed Envoy tradeoff
- systems/istio — canonical Envoy-as-sidecar mesh
- systems/aws-app-mesh — AWS's customer-managed-Envoy mesh (EOL 2026-09-30)
- systems/aws-ecs-service-connect — AWS's managed-Envoy replacement