Learn the vocabulary of a language-agnostic L7 proxy handling load balancing and observability as a sidecar.
0 / 5 completed
1 / 5
At standup, a dev mentions a high-performance L7 proxy deployed alongside each service instance to handle load balancing, retries, and observability without any application code change. What proxy is being described?
Envoy proxy is a high-performance L7 proxy deployed alongside each service instance to handle load balancing, retries, and observability without requiring any change to the application's own code. A simple TCP-level load balancer has no visibility into HTTP-level concerns like a specific request path or header, limiting how much intelligent routing or retry logic it can apply. This L7 awareness is what makes Envoy the common data-plane choice underlying many service mesh implementations.
2 / 5
During a design review, the team wants Envoy to fetch its routing and cluster configuration dynamically from a control plane at runtime, rather than reading a static configuration file that requires a restart to update. Which capability supports this?
Dynamic configuration via Envoy's xDS APIs lets it fetch its routing and cluster configuration dynamically from a control plane at runtime, updating its behavior without requiring a restart. Reading only a static configuration file loaded once at startup forces a restart, and the resulting brief disruption, every time the routing configuration needs to change. This dynamic configuration capability is what lets a service mesh control plane push a routing update across an entire fleet of Envoy instances smoothly.
3 / 5
In a code review, a dev notices Envoy is configured with an outlier detection policy that temporarily ejects an upstream host from the load-balancing pool after it returns too many consecutive errors. What does this represent?
Outlier detection temporarily ejects an upstream host from Envoy's load-balancing pool after it returns too many consecutive errors, keeping traffic away from a host that's actively failing. Continuing to send traffic to every host indefinitely, with no ejection, keeps routing requests to a host that's likely to keep failing them. This automatic ejection is what lets Envoy's load balancing adapt to a real-time failure without waiting for a person to notice and intervene manually.
4 / 5
An incident report shows requests kept being routed to an upstream host that was already failing nearly every request, because outlier detection had never been configured on the Envoy proxy sitting in front of that service. What practice would prevent this?
Configuring outlier detection lets Envoy automatically eject a persistently failing upstream host from its load-balancing pool, keeping traffic away from a host that's clearly struggling. Leaving outlier detection unconfigured is exactly what let requests keep being routed to a nearly-always-failing host in this incident. This configuration is a standard resilience feature for any Envoy deployment sitting in front of a service with multiple upstream instances.
5 / 5
During a PR review, a teammate asks why the team deploys Envoy proxy alongside each service instead of building retry logic, load balancing, and observability directly into every application's own codebase. What is the reasoning?
Envoy provides the same reusable, language-agnostic networking behavior to every service unchanged, letting one maintained proxy configuration serve many different applications regardless of what language each is written in. Building that same logic directly into every application duplicates it across every codebase, multiplying the maintenance burden considerably. The tradeoff is the added resource overhead and operational complexity of running and configuring an extra proxy instance alongside every service.