Service Mesh
Also Known As
Istio
Linkerd
Envoy proxy
sidecar proxy
TL;DR
Infrastructure layer handling service-to-service communication — mutual TLS, observability, retries, circuit breaking, and traffic shaping without application code changes.
Explanation
A service mesh deploys a proxy sidecar (Envoy) alongside each service. All traffic flows through sidecars — enabling: mTLS between services (zero-trust networking), distributed tracing (automatic span injection), traffic management (canary routing, weighted traffic), circuit breaking, retries, and rate limiting at the infrastructure level. Istio and Linkerd are the main implementations. PHP applications gain these features automatically — no SDK integration needed. The trade-off: operational complexity and latency overhead of an extra network hop per request.
Diagram
flowchart LR
subgraph Service A Pod
APP_A[PHP App]
PROXY_A[Envoy Sidecar]
end
subgraph Service B Pod
APP_B[PHP App]
PROXY_B[Envoy Sidecar]
end
CP[Control Plane<br/>Istio / Linkerd]
APP_A <--> PROXY_A
APP_B <--> PROXY_B
PROXY_A -->|mTLS + traces + retries| PROXY_B
CP -.->|config: routes<br/>policies, certs| PROXY_A & PROXY_B
style APP_A fill:#1f6feb,color:#fff
style APP_B fill:#1f6feb,color:#fff
style PROXY_A fill:#238636,color:#fff
style PROXY_B fill:#238636,color:#fff
style CP fill:#6e40c9,color:#fff
Common Misconception
✗ A service mesh is required for microservices — service meshes add significant operational complexity; many microservice deployments run perfectly well with simpler solutions like TLS, application-level retry logic, and basic observability.
Why It Matters
Service meshes solve cross-cutting concerns (auth, observability, resilience) at the infrastructure layer — PHP services gain mTLS and distributed tracing without any code changes.
Common Mistakes
- Adopting a service mesh before needing it — it solves real problems at scale but adds overhead for small setups.
- Not measuring the latency overhead — each hop adds ~1-3ms which compounds in deep call chains.
- Using a service mesh without understanding Envoy config — debugging proxy issues requires mesh knowledge.
- Overlapping retry logic in both app and mesh — double retries cause non-idempotent request duplication.
Code Examples
✗ Vulnerable
// Without service mesh: each service implements cross-cutting concerns:
class PaymentClient {
public function charge(array $data): array {
// Each service manually implements:
// - TLS cert management
// - Retry logic with backoff
// - Circuit breaker
// - Trace injection
// - Rate limiting
// Duplicated across every service
}
}
✓ Fixed
// With service mesh (Istio):
// Sidecar proxy handles automatically:
// - mTLS between all services (zero trust)
// - Automatic retry on 503 (3 attempts, exponential backoff)
// - Circuit breaking at 50% error rate
// - Trace ID injection into all requests
// - Canary routing: 10% to v2, 90% to v1
// PHP service code remains simple:
$response = $this->httpClient->post('http://payment-service/charge', $data);
// Proxy intercepts, adds mTLS, traces, handles retries
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
16 Mar 2026
Edited
22 Mar 2026
Views
18
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 6
Perplexity 4
Unknown AI 2
Google 1
Ahrefs 1
Also referenced
How they use it
crawler 14
Related categories
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: High
⚡ Quick Fix
Add Istio or Linkerd to your Kubernetes cluster to get mTLS, circuit breaking, distributed tracing, and traffic management without changing a line of PHP code — the sidecar proxy handles it all
📦 Applies To
any
web
api
🔗 Prerequisites
🔍 Detection Hints
PHP microservices without mTLS between services; circuit breaking and retry logic duplicated in each PHP service; no distributed tracing across services
Auto-detectable:
✗ No
istio
linkerd
consul
envoy
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: High
Context: File