Microservices
Microservices architecture best practices
Best Practices
CNCF Cloud-Native Definition & Principles
The CNCF’s formal definition of cloud-native computing and core principles for micro-services, containers, and dynamic orchestration.
by Cloud Native Computing FoundationProduction-Ready Micro-services Checklist
A checklist covering operability, reliability, deployability, and observability of micro-services.
by Susan FowlerContract-Driven Development with Pact
Consumer-driven contract testing methodology to ensure micro-service compatibility.
by Pact FoundationDistributed Tracing Best Practices
Techniques for instrumenting and propagating trace context across services so requests can be followed end-to-end, with sampling and span design that aid debugging.
by OpenTelemetry (CNCF)CQRS (Command Query Responsibility Segregation)
An architecture pattern that separates the model that writes data (commands) from the model that reads it (queries), allowing each side to scale and evolve independently.
by Martin FowlerEvent Sourcing
An architecture pattern that stores every change to application state as an immutable sequence of events, making the event log the source of truth instead of current state.
by Martin FowlerSaga Pattern
A pattern for managing data consistency across microservices using a sequence of local transactions coordinated by events or a central orchestrator, with compensating actions on failure.
by MicrosoftCircuit Breaker Pattern
A resilience pattern that stops calls to a failing dependency once errors cross a threshold, preventing cascading failures and giving the dependency time to recover.
by Martin FowlerBulkhead Pattern
A resilience pattern that isolates resources into separate pools so a failure or overload in one part of a system cannot consume the resources others depend on.
by MicrosoftBackends for Frontends (BFF)
An architecture pattern that gives each frontend client its own tailored backend service, instead of forcing web, mobile, and other clients to share one general-purpose API.
by Sam NewmanAPI Gateway Pattern
An architecture pattern that places a single entry point in front of backend services to handle routing, authentication, rate limiting, and other cross-cutting concerns.
by MicrosoftService Mesh Best Practices
Guidance for using a service mesh to manage service-to-service traffic, security, and observability through sidecar proxies, keeping that logic out of application code.
by Cloud Native Computing FoundationSidecar Pattern
A design pattern that deploys a helper component alongside the main application in the same unit, adding capabilities like proxying, logging, or config without changing the app.
by MicrosoftDomain-Driven Design (DDD)
A software design approach that models complex business domains in code, using a shared language and bounded contexts to align software structure with the business it serves.
by Eric EvansModular Monolith
An architecture that keeps a single deployable application but enforces strong internal module boundaries, capturing many microservices benefits without distributed-system complexity.
by ThoughtWorksgRPC Best Practices
Guidance for building high-performance gRPC services with Protocol Buffers: service design, streaming, deadlines, error codes, and backward-compatible schema evolution.
by Cloud Native Computing FoundationMicro-Frontends
An architecture that splits a web app into independently developed and deployed frontend pieces owned by separate teams, then composes them into one experience.
by Cam Jackson / ThoughtworksPatterns
API Gateway
A single entry point that routes, aggregates, and secures client requests across many backend microservices.
Service Registry
A database of available service instances and their network locations, kept current as instances start, stop, and fail.
Service Discovery
A mechanism for clients to find the current network location of a service without hard-coding addresses.
API Composition
Implements a query that spans multiple services by invoking each owner service and joining the results in memory.
CQRS (Command Query Responsibility Segregation)
Separates the model that writes data (commands) from the model that reads it (queries) so each can be optimized independently.
Aggregator
A component that invokes multiple services and combines their responses into a single consolidated result for the caller.
Choreography
Coordinates a distributed workflow through services reacting to each other's events, with no central controller.
Orchestration
Coordinates a distributed workflow through a central orchestrator that explicitly invokes each service in sequence.
Message Router
Consumes a message and redirects it to a different channel based on conditions, decoupling producers from the decision of where messages should go.
Content-Based Router
Routes each message to a destination channel chosen by inspecting the message's content, so the payload itself determines where it is delivered.
Routing Slip
Attaches a sequence of processing steps to a message so it routes itself through a series of components determined per message at runtime.
Process Manager
A central component that maintains the state of a multi-step message flow and decides the next step, coordinating complex or branching workflows.
Retry with Backoff
Automatically re-attempts a failed operation after progressively longer waits, smoothing over transient faults without overwhelming a struggling dependency.
Exponential Backoff with Jitter
Adds randomness to exponentially growing retry delays so that many clients do not retry in lockstep and overwhelm a recovering service.
Timeout
Bounds how long a caller waits for an operation, freeing resources and surfacing failures fast instead of blocking indefinitely on a slow or hung dependency.
Bulkhead
Isolates resources into independent pools so a failure or overload in one part of a system cannot consume capacity needed by the rest.
Fallback
Provides an alternative response or behavior when a primary operation fails, keeping the system useful instead of returning an error to the user.
Fail Fast
Detects invalid state or unavailable dependencies as early as possible and reports the error immediately, rather than continuing into deeper, costlier failure.
Backpressure
Lets a slow consumer signal upstream producers to slow down, preventing unbounded queues and memory exhaustion when demand exceeds processing capacity.
Tutorials
How to install Istio and enable mTLS for service-to-service traffic
Deploy Istio, enable automatic sidecar injection, and turn on strict mutual TLS between services.
How to add a lightweight service mesh with Linkerd
Install Linkerd, mesh a workload, and gain automatic mTLS plus golden-metrics observability with low overhead.
Checklists
Monolith Decomposition Readiness Checklist
Verify a monolithic application is understood, instrumented, and bounded well enough to begin safe decomposition into services.
Microservice Production-Readiness Checklist
Confirm a new or extracted microservice meets operational, security, and resilience bars before it serves production traffic.
Service Extraction Cutover Checklist
Cutover checks for routing live traffic from a monolith to a newly extracted service without downtime or data loss.
Event-Driven Architecture Readiness Checklist
Confirm readiness to adopt event-driven communication between services, covering schemas, delivery semantics, and observability.
Database-Per-Service Decoupling Checklist
Separate a shared database into per-service ownership so microservices can deploy and scale independently without hidden coupling.
gRPC Rollout Checklist
Pre-flight items for rolling out gRPC services across a system, covering contracts, compatibility, security, and observability.
Microservices API Contract Testing Checklist
Verification items for establishing consumer-driven contract testing across microservices to prevent integration breakage.
Technology Stacks
Go + gRPC Stack
Compiled Go backend stack using gRPC and Protocol Buffers with PostgreSQL for fast, strongly-typed inter-service communication.
Micronaut JVM Microservices Stack
JVM microservices stack using Micronaut with ahead-of-time compilation and PostgreSQL for low-memory, fast-starting services and serverless functions.
Event-Driven Microservices Stack
Asynchronous microservices architecture using Kafka as an event backbone with independently deployable services for loose coupling and scalability.
gRPC Service Mesh Stack
Microservices stack combining gRPC inter-service communication with a service mesh on Kubernetes for typed, observable, secure service-to-service traffic.
Dapr Distributed Application Stack
Polyglot microservices stack using Dapr building blocks for service invocation, state, pub/sub, and bindings, abstracted from underlying infrastructure.
Vert.x Reactive Stack
A polyglot, event-driven toolkit on the JVM built around a non-blocking event loop and the reactor pattern for high-concurrency, low-latency services.
Spring WebFlux Reactive
Spring's reactive, non-blocking web stack built on Project Reactor and Netty, for high-concurrency services that need backpressure and efficient resource use.
FAQs
What is a service mesh?
A service mesh is an infrastructure layer that manages communication between microservices, handling traffic routing, load balancing, retries, encryption, and observability without changing application code. It typically works by injecting a lightweight proxy (a sidecar) alongside each service that intercepts all network traffic. Popular implementations include Istio, Linkerd, and Consul. A service mesh is most valuable in large microservice deployments where consistent security, reliability, and telemetry are needed across many services.
What is a sidecar container?
A sidecar is a secondary container that runs alongside the main application container in the same pod to extend or support it without changing the application itself. Common uses include log shipping, metrics collection, configuration syncing, and acting as a service-mesh proxy. Because containers in a pod share the network and can share storage, the sidecar can transparently intercept traffic or read and write the same files. The sidecar pattern keeps cross-cutting concerns separate from business logic and reusable across services.
What is a microservice?
A microservice is a small, independently deployable service that owns a single business capability and communicates with other services over the network, typically via HTTP/REST, gRPC, or messaging. Each microservice has its own codebase and usually its own data store, allowing teams to develop, deploy, and scale it without coordinating with the rest of the system. The trade-off for this independence is added operational complexity: distributed transactions, network failures, and observability across many services all become harder.
What is event-driven architecture?
Event-driven architecture is a style where components communicate by producing and reacting to events—records that something happened—rather than calling each other directly. Producers publish events to a broker or stream such as Kafka or a message queue, and consumers subscribe and act independently and asynchronously. This decouples services, improves scalability, and lets new consumers be added without changing producers. The trade-offs are eventual consistency, harder debugging, and the need to handle duplicate or out-of-order events.
See a real scan run
A replay of the actual CLI running against our test repositories — live progress, real findings, a genuine DriftScore. Nothing executes in your browser.