Architecture Patterns
A dedicated infrastructure layer that handles service-to-service communication in a microservices architecture — encryption, retries, observability, traffic shaping — outside application code.
A service mesh is a layer of network infrastructure that handles communication between services. It typically deploys a lightweight proxy (a sidecar like Envoy) next to each service instance. The sidecar intercepts all network traffic in and out of the service, enabling the mesh to add features without changing application code: mutual TLS encryption, retries, circuit breaking, traffic shifting (blue/green, canary), distributed tracing, and rich metrics.
The popular implementations — Istio, Linkerd, Consul Connect, AWS App Mesh — separate the data plane (the sidecars handling traffic) from the control plane (the API and configuration store that programs them). This separation lets platform teams centralize policy while service teams remain focused on application logic.
Service meshes are most valuable in large microservice deployments where consistent network behavior matters across many services in many languages. They are overkill for small systems, where library-based equivalents (gRPC retries, OpenTelemetry SDK, Spring Cloud) are simpler.
Adopt a service mesh when you have dozens of services across multiple languages and need consistent security, observability, and traffic management across all of them.
Service meshes add operational complexity (the sidecar must be deployed and managed everywhere), latency (every hop adds milliseconds), and require platform-team expertise to operate well.
An architectural style that structures an application as a collection of small, independently deployable services, each responsible for a specific business capability.
A single entry point that routes external requests to internal services, handling concerns like authentication, rate limiting, and request transformation in one place.
A pattern that stops calls to a failing downstream service for a cool-off period to prevent cascading failures and give the service time to recover.
A single deployable application containing all features and logic, sharing one codebase, one database, and one deployment unit.
An architectural style where services communicate primarily by emitting and reacting to events, rather than calling each other directly.
A pattern that separates the model used for writing data (commands) from the model used for reading data (queries), allowing each to be optimized independently.