Service mesh
Related service Website & online shop
DEFINITION
A service mesh is an infrastructure layer (Istio, Linkerd, Cilium Service Mesh, Consul) that intercepts every network call between microservices: service-to-service mTLS, retry, timeout, circuit breaker, traffic split (canary, blue-green), observability, and policy enforcement. The logic moves out of your application into a sidecar proxy (Envoy) or an eBPF layer, so it is language-agnostic. It sounds compelling, and vendors love selling it. In reality: if you have fewer than 8 services, if everything is one language (say gRPC), and Kubernetes is a single familiar cluster, then 80 percent of what a mesh would do can be solved with a good library (gRPC retry, OpenTelemetry, cert-manager) plus Kubernetes NetworkPolicy. You actually need a mesh when many languages plus many teams plus strict zero-trust (PCI, fed) plus multi-cluster topology combine. Otherwise the operational cost (control plane, sidecar memory, debugging) eats the benefit.
- SSR (Server-Side Rendering)→
HTML rendered by the server per-request, fresh for every user. Ideal for dynamic content (dashboards), but slower than SSG.
- SSG (Static Site Generation)→
Pages are produced at build time as HTML and served from a CDN. Near-zero TTFB. DField's own site runs this way across 111+ pages.
- ISR (Incremental Static Regeneration)→
SSG + timed regeneration: the HTML is static but regenerates on a schedule. Ideal for blog content · freshness with CDN speed.
- Edge rendering→
Code runs at the CDN edge closest to the user (Cloudflare Workers, Vercel Edge). Dynamic responses with ~10–50 ms TTFB.
- RSC (React Server Components)→
React components that run exclusively on the server and never ship to the browser. Result: less client-side JS and faster hydration.
- LCP (Largest Contentful Paint)→
Time until the largest visible element paints. Google Core Web Vitals passes under 2.5s · we usually land marketing pages under 1s.