Microservices architecture structures applications as collections of independently deployable, loosely coupled services that communicate over well-defined APIs. Unlike monolithic architectures where all components exist in a single codebase, microservices enable teams to develop, deploy, and scale services independently, making them ideal for complex, distributed systems. The architecture brings operational complexity—distributed tracing, service discovery, data consistency—but when applied correctly, it delivers organizational agility, fault isolation, and the ability to evolve technology stacks per service. The key to success lies not in breaking everything into microservices, but in defining service boundaries that align with business capabilities and minimize inter-service chatter; as of 2026, the industry has matured toward smart consolidation, sidecar-less service meshes, and modular monolith–first approaches before committing to full decomposition.
What This Cheat Sheet Covers
This topic spans 19 focused tables and 138 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Architectural Patterns
| Pattern | Example | Description |
|---|---|---|
Kong Gateway routes /orders to Order Service, /users to User Service | • Single entry point that routes client requests to appropriate microservices • handles cross-cutting concerns like authentication, rate limiting, and protocol translation | |
Istio sidecar proxies intercept all traffic between services | • Infrastructure layer providing service-to-service communication, observability, traffic management, and security without changing application code • uses sidecar pattern or sidecar-less eBPF | |
Mobile BFF aggregates 5 API calls into 1, Web BFF returns full dataset | Dedicated backend per client type (mobile, web, IoT) that tailors API responses to specific UI requirements and device capabilities | |
Each microservice owns PostgreSQL, MongoDB, or Redis instance | • Each service has exclusive ownership of its data store • prevents tight coupling through shared databases and enables independent schema evolution | |
Order Service publishes OrderPlaced event to Kafka topic | • Services communicate via asynchronous events rather than synchronous calls • enables loose coupling and temporal decoupling between services | |
Payment fails → compensating transactions refund inventory, cancel order | Manages distributed transactions across services using choreography (event chain) or orchestration (central coordinator) with compensating actions for rollback |