API Gateway
An API gateway is a single entry point that sits in front of a set of microservices and routes client requests to the appropriate service. It commonly handles cross-cutting concerns such as authentication, rate limiting, TLS termination, request aggregation, and protocol translation. By centralising these concerns it keeps individual services focused on business logic, at the cost of being a component that must itself be made highly available.
Aggregator Pattern
The aggregator pattern composes a single response from several downstream services, either inside an API gateway (the gateway-aggregation pattern) or in a dedicated composition service. It reduces chatty client-to-service traffic and lets the caller make one request instead of many. The trade-off is added latency coupling and the need to handle partial failures of the downstream calls.
Backend for Frontend (BFF)
A Backend for Frontend is a server-side component tailored to the needs of one specific client experience, such as a mobile app or a web SPA. Instead of a single general-purpose API, each frontend gets its own backend that aggregates and shapes data for that client. This avoids over-fetching and lets client teams evolve their BFF independently of the underlying services.
Bounded Context
In Domain-Driven Design a bounded context is an explicit boundary within which a particular domain model and its ubiquitous language are consistent. Bounded contexts are the natural seams along which to split a system into services, because each context owns a cohesive slice of the domain with minimal overlap. Aligning service boundaries to bounded contexts reduces cross-service coupling.
Bulkhead
The bulkhead pattern isolates resources such as thread pools or connection pools so that a failure or saturation in one part of a system cannot exhaust resources needed by the rest. It is named after the watertight compartments in a ship's hull. In microservices it prevents one slow dependency from consuming all threads and taking down an entire service.
Choreography
Choreography is a way of coordinating a distributed workflow in which each service reacts to events and emits its own events, with no central coordinator. It produces loose coupling and good autonomy but makes the end-to-end flow harder to observe and reason about. It contrasts with orchestration, where a central component drives the steps.
Circuit Breaker
A circuit breaker is a resilience pattern that monitors calls to a remote dependency and, after a threshold of failures, trips open to fail fast instead of waiting on a failing service. After a cooldown it allows a few trial calls (half-open) to test recovery before closing again. It prevents cascading failures and gives a struggling dependency room to recover.
Consumer-Driven Contract
A consumer-driven contract is a test artefact in which the consumer of an API declares the exact requests it makes and responses it expects, and the provider verifies it can satisfy every consumer's contract. It catches breaking API changes in CI before deployment, without the brittleness of full end-to-end tests. Tools such as Pact implement this pattern.
Container
A container packages an application together with its runtime, libraries, and configuration into an isolated, portable unit that runs consistently across environments. Containers share the host kernel, which makes them lighter than virtual machines. In microservices each service is typically built as a container image and deployed independently.
Container Orchestration
Container orchestration automates the deployment, scaling, networking, and lifecycle management of containers across a cluster of machines. It handles scheduling, health checking, self-healing, and rolling updates. Kubernetes is the de facto standard orchestrator for microservices.
Dead Letter Queue (DLQ)
A dead letter queue is a queue where messages are sent when they cannot be processed successfully after a configured number of attempts. It prevents a poison message from blocking a consumer indefinitely and preserves the failed message for inspection and replay. DLQs are essential for operating reliable event-driven systems.
Distributed Tracing
Distributed tracing follows a single request as it propagates across multiple services by attaching and forwarding a correlation context of trace and span identifiers. It reconstructs the end-to-end path and timing of a request, which is essential for diagnosing latency and failures in a microservices system. OpenTelemetry is the dominant standard for instrumenting traces.
Domain-Driven Design (DDD)
Domain-Driven Design is an approach that centres software design on a rich model of the business domain, expressed in a shared ubiquitous language. Its strategic patterns of bounded contexts and context mapping are widely used to identify where to draw microservice boundaries. Its tactical patterns of aggregates, entities, and value objects shape the internal model of a service.
Eventual Consistency
Eventual consistency is a consistency model in which, given no new updates, all replicas of a piece of data will converge to the same value over time, but may be temporarily inconsistent. Distributed systems often accept eventual consistency to gain availability and partition tolerance. It requires the application and users to tolerate reading slightly stale data.
Event Sourcing
Event sourcing persists the state of an entity as an append-only sequence of immutable events rather than as current state. The current state is derived by replaying the events, which yields a complete audit log and enables temporal queries and rebuilding read models. It is more complex than CRUD storage and is usually justified only when the event history itself has business value.
Event-Driven Architecture
Event-driven architecture is a style in which services communicate by producing and consuming events, typically through a message broker, rather than by direct synchronous calls. It promotes loose coupling and resilience because producers do not need to know who consumes their events. The trade-off is harder end-to-end reasoning and the need for idempotent, eventually consistent handling.
Fault Tolerance
Fault tolerance is the ability of a system to continue operating, possibly in a degraded mode, despite the failure of some of its components. In microservices it is achieved with patterns such as timeouts, retries, circuit breakers, bulkheads, and fallbacks. The goal is to contain failures so that one failing service does not bring down the whole system.
Idempotency
An operation is idempotent if performing it multiple times has the same effect as performing it once. Idempotency is critical in distributed systems because retries and at-least-once delivery can cause duplicate requests. It is commonly implemented with an idempotency key that the server deduplicates on, or by designing the operation to be naturally repeatable.
Kubernetes
Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and operations of containerised applications across clusters. It exposes declarative APIs for desired state, such as Deployments, Services, and ConfigMaps, and continuously reconciles actual state toward it. It is the most widely used platform for running microservices in production.
Loose Coupling
Loose coupling means that services have minimal knowledge of and dependency on one another's internals, interacting only through stable contracts. It lets a service be changed, deployed, and scaled independently without forcing changes in others. Achieving loose coupling is a primary goal of microservice design and is undermined by shared databases or chatty synchronous chains.
Message Broker
A message broker is middleware that receives messages from producers and delivers them to consumers, decoupling the two in time and space. It supports patterns such as queues for point-to-point delivery and topics for publish-subscribe, and often provides durability, ordering guarantees, and delivery retries. Apache Kafka and RabbitMQ are common brokers in microservice systems.
Microservice
A microservice is a small, independently deployable service that is built around a single business capability and owns its own data. Microservices communicate over a network through well-defined APIs or events and can be developed, deployed, and scaled independently of one another. The style trades the simplicity of a monolith for autonomy and scalability at the cost of distributed-systems complexity.
Modular Monolith
A modular monolith is a single deployable application organised into well-defined, loosely coupled modules with explicit internal boundaries. It captures much of the maintainability benefit of microservices without the operational cost of a distributed system. It is often the recommended starting point and the safest unit from which to later extract services.
Observability
Observability is the degree to which the internal state of a system can be inferred from its external outputs, typically its logs, metrics, and traces, known as the three pillars. In a microservices system, where a request spans many services, strong observability is essential for understanding behaviour and diagnosing problems. It goes beyond monitoring by enabling exploration of unanticipated questions.
Orchestration
Orchestration coordinates a distributed workflow through a central component that explicitly invokes each step and handles its outcome. It makes the overall process easy to see and change in one place, at the cost of the orchestrator becoming a point of coupling and a potential bottleneck. It contrasts with choreography, where coordination emerges from services reacting to events.
Outbox Pattern
The transactional outbox pattern reliably publishes events by writing them, in the same local database transaction as the business state change, to an outbox table. A separate process then reads the outbox and publishes the events to the broker, guaranteeing that an event is published if and only if the state change committed. It solves the dual-write problem between a database and a message broker.
Polyglot Persistence
Polyglot persistence is the practice of using different data storage technologies for different services or workloads, choosing each store to fit its data and access patterns. One service might use a relational database, another a document store, and another a search index. It is enabled by the database-per-service principle and increases operational diversity.
Resilience
Resilience is a system's ability to absorb faults and recover from disruption while continuing to provide acceptable service. In microservices it is engineered deliberately through timeouts, retries with backoff, circuit breakers, bulkheads, rate limiting, and graceful degradation. It accepts that failures are inevitable in distributed systems and plans for them.
Saga
A saga is a pattern for managing a business transaction that spans multiple services by breaking it into a sequence of local transactions, each with a compensating action to undo it on failure. It replaces the impossible distributed ACID transaction with eventual consistency and explicit compensation. Sagas can be coordinated by choreography through events or by orchestration through a central coordinator.
Service Discovery
Service discovery is the mechanism by which services find the network locations of the instances they need to call, without those locations being hardcoded. It uses a registry that instances register with and clients query, supporting dynamic scaling and instance churn. It can be client-side, where the client picks an instance, or server-side, where a load balancer or platform does.
Service Mesh
A service mesh is a dedicated infrastructure layer that handles service-to-service communication, typically by injecting a sidecar proxy alongside each service instance. It provides traffic management, mutual TLS, retries, timeouts, and telemetry transparently, without changing application code. Istio and Linkerd are well-known implementations.
Service Registry
A service registry is a database of the available service instances and their network locations, kept up to date as instances start, stop, and fail health checks. Clients or load balancers query it to perform service discovery. Examples include Consul, etcd, and the registry built into Kubernetes.
Sidecar
A sidecar is a helper container deployed alongside a main application container in the same unit, such as a Kubernetes pod, sharing its lifecycle and network namespace. It adds capabilities like proxying, logging, or configuration without modifying the application. The service mesh data plane is the most prominent use of the sidecar pattern.
Strangler Fig Pattern
The strangler fig pattern incrementally migrates a legacy system by routing specific functionality to new services while the old system keeps running, gradually replacing it until it can be retired. It avoids a risky big-bang rewrite by delivering and validating value in small steps. The name comes from a vine that grows around a tree and eventually supplants it.
Synchronous Communication
Synchronous communication is request-response interaction in which the caller blocks and waits for the callee to respond, as with a typical REST or gRPC call. It is simple to reason about but couples the caller's availability and latency to the callee's. Overusing synchronous chains across many services creates fragile, latency-prone call graphs.
Asynchronous Communication
Asynchronous communication is interaction in which the sender does not block waiting for an immediate response, usually mediated by messages or events through a broker. It decouples services in time, improves resilience, and smooths load spikes, at the cost of eventual consistency and harder debugging. It is the preferred style for cross-service workflows that do not need an immediate answer.
Twelve-Factor App
The Twelve-Factor App is a methodology of twelve principles for building cloud-native, deployable services, covering configuration, dependencies, statelessness, port binding, concurrency, and disposability. Microservices commonly follow it, especially storing configuration in the environment and treating processes as stateless and disposable. It predates but strongly informs container-native design.
Ubiquitous Language
The ubiquitous language is the shared vocabulary, used consistently by developers and domain experts, that names the concepts of a bounded context. It removes translation between business and code by making the model and its terminology one and the same. Each bounded context, and therefore often each microservice, has its own ubiquitous language.
Service-Level Objective (SLO)
A service-level objective is a target value or range for a service-level indicator, such as 99.9% of requests succeeding or p99 latency below 300 ms over a rolling window. SLOs make reliability measurable and drive decisions about whether to ship features or invest in stability. They underpin error budgets in site reliability engineering.
Sticky Session
A sticky session, or session affinity, routes all requests from a given client to the same service instance, usually so that in-memory session state is found there. It conflicts with the microservices preference for stateless, horizontally scalable instances and complicates scaling and failover. The recommended alternative is to externalise session state to a shared store.
Database per Service
Database per service is the principle that each microservice owns its data exclusively and other services may not access that data directly, only through the owning service's API. It enforces loose coupling and lets each service choose the storage best suited to it. It rules out shared-database integration and forces cross-service data needs to be met by APIs, events, or data replication.
CQRS
Command Query Responsibility Segregation separates the model used to change state (commands) from the model used to read state (queries), allowing each to be optimised and scaled independently. In microservices it often pairs with event-driven updates that build denormalised read models. It adds complexity and is justified only when read and write workloads diverge significantly.
Two-Phase Commit (2PC)
Two-phase commit is a distributed atomic-commit protocol in which a coordinator asks all participants to prepare, then tells them all to commit or abort. It provides strong consistency but blocks if the coordinator fails and scales poorly, so it is generally avoided across microservices in favour of sagas and eventual consistency. It remains relevant within a single transactional resource.
Health Check
A health check is an endpoint or probe a service exposes so that orchestrators and load balancers can determine whether it is alive and ready to serve traffic. A liveness check detects a hung process that should be restarted, while a readiness check detects whether the instance can currently accept requests. Kubernetes uses these probes to manage routing and restarts.
Blue-Green Deployment
A blue-green deployment runs two identical production environments, one live and one idle, deploying the new version to the idle one and switching traffic over once it is verified. It enables near-instant rollback by switching traffic back. It requires double the capacity during the switch and careful handling of database schema changes.
Canary Release
A canary release rolls out a new version to a small subset of traffic or users first, monitors it, and gradually increases exposure only if metrics stay healthy. It limits the blast radius of a bad release and supports automated rollback on regression. It depends on solid observability and the ability to route traffic by percentage.
gRPC
gRPC is a high-performance remote procedure call framework that uses HTTP/2 for transport and Protocol Buffers for interface definition and binary serialization. It supports unary and streaming calls and generates strongly typed client and server stubs from a shared schema. It is a common choice for efficient internal service-to-service communication where both sides are controlled.
Correlation ID
A correlation ID is a unique identifier attached to a request when it enters the system and propagated through every downstream call and log line it produces. It lets operators stitch together all the activity belonging to one logical request across many services. It is the foundation of distributed tracing and of debugging in a microservices environment.