Microservices Architecture Cheat Sheet

Updated 2026-04-29

Next Topic: Modular Monolith Architecture Cheat Sheet

🧠Study flashcards on this topic132 cards · spaced repetition→

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, 132 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Architectural PatternsTable 2: Service Communication PatternsTable 3: Data Management PatternsTable 4: Service Discovery and RegistryTable 5: Resilience and Fault Tolerance PatternsTable 6: Observability and MonitoringTable 7: Deployment PatternsTable 8: Security PatternsTable 9: Testing PatternsTable 10: Scalability PatternsTable 11: Domain-Driven Design DecompositionTable 12: Configuration ManagementTable 13: Anti-Patterns to AvoidTable 14: Service Mesh ImplementationsTable 15: API Gateway SolutionsTable 16: Message Brokers and Event StreamingTable 17: Distributed Tracing ToolsTable 18: Container Orchestration PlatformsTable 19: Service Versioning Strategies

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Architectural Patterns

These are the structural building blocks you assemble a microservices system from — the gateway that fronts your services, the mesh that wires them together, and the data and transaction patterns (Saga, CQRS, Event-Driven) that keep them consistent without a shared database. Most real architectures combine several of these rather than picking one, and knowing what each solves is the difference between a clean decomposition and a distributed monolith.

Pattern	Example	Description
API Gateway	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
Service Mesh	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
Backend for Frontend (BFF)	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
Database per Service	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
Event-Driven Architecture	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
Saga Pattern	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
CQRS (Command Query Responsibility Segregation)	Write model uses PostgreSQL normalized tables; read model uses Elasticsearch denormalized docs	Separates write operations (commands) from read operations (queries) using different data models optimized for their specific access patterns
Strangler Fig Pattern	API Gateway routes `/legacy/` to monolith, `/v2/` to new services	• Incrementally migrates monolith to microservices by routing traffic to new services while legacy system continues running • no big-bang rewrite
Sidecar Pattern	Envoy proxy container runs alongside app container in same pod	Helper container deployed alongside main application container to provide auxiliary capabilities like logging, monitoring, or configuration without modifying app code
Circuit Breaker	After 5 failed calls, circuit opens for 30s; requests fail fast	• Prevents cascading failures by detecting failures and stopping requests to unhealthy services • transitions between closed, open, and half-open states
Microservice Chassis	Spring Boot starter handles logging, health checks, metrics, distributed tracing for every service	Reusable framework and build logic that handles cross-cutting concerns (logging, health, metrics, config, tracing) so each new service gets them without boilerplate

Table 2: Service Communication Patterns

Once services are split apart, how they talk to each other shapes everything else — latency, coupling, and resilience. The fundamental fork is synchronous (REST, gRPC) where the caller waits, versus asynchronous (messaging, pub/sub) where it doesn't; the former is simpler to reason about, the latter buys you loose coupling and the ability to absorb load. Reach for these deliberately, since over-using blocking calls is the fastest path to cascading failures.

Pattern	Example	Description
Synchronous Request-Response (REST)	`GET /api/users/123` returns user JSON over HTTP	• Client sends request and blocks waiting for response • simple, universal, and cacheable • creates tight temporal coupling between caller and callee

The rest of this section is part of the full cheat sheet

Table 3: Data Management Patterns

The hardest part of microservices isn't the code — it's the data, because each service owns its own store and there are no cross-service transactions to lean on. These patterns are the toolkit for keeping data consistent and events reliably published despite that constraint: event sourcing and CDC give you trustworthy change streams, the outbox and inbox patterns close the dual-write and duplicate-delivery gaps, and eventual consistency is the trade-off you accept in return for availability.

Pattern	Example	Description
Event Sourcing	Account history: `Created($100)` → `Deposited($50)` → `Withdrawn($30)` = $120 balance	• Stores all state changes as immutable events in append-only log • current state derived by replaying events • enables audit trail and time travel

The rest of this section is part of the full cheat sheet

Table 4: Service Discovery and Registry

When instances scale up, down, and move between hosts, hardcoded addresses stop working — services need a live registry to find each other. The choices here come down to two questions: who does the lookup (the client itself or a load balancer in front of it) and who registers the instance (the service itself or an external registrar like Kubernetes).

Pattern	Example	Description
Client-Side Discovery	Client queries Consul registry, gets instance list, load balances directly	• Client queries service registry to get available instances and performs load balancing • gives client control but increases complexity

The rest of this section is part of the full cheat sheet

Table 1: Core Architectural Patterns

Pattern	Example	Description
API Gateway	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
Service Mesh	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
Backend for Frontend (BFF)	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
Database per Service	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
Event-Driven Architecture	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
Saga Pattern	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
CQRS (Command Query Responsibility Segregation)	Write model uses PostgreSQL normalized tables; read model uses Elasticsearch denormalized docs	Separates write operations (commands) from read operations (queries) using different data models optimized for their specific access patterns
Strangler Fig Pattern	API Gateway routes `/legacy/` to monolith, `/v2/` to new services	• Incrementally migrates monolith to microservices by routing traffic to new services while legacy system continues running • no big-bang rewrite
Sidecar Pattern	Envoy proxy container runs alongside app container in same pod	Helper container deployed alongside main application container to provide auxiliary capabilities like logging, monitoring, or configuration without modifying app code
Circuit Breaker	After 5 failed calls, circuit opens for 30s; requests fail fast	• Prevents cascading failures by detecting failures and stopping requests to unhealthy services • transitions between closed, open, and half-open states
Microservice Chassis	Spring Boot starter handles logging, health checks, metrics, distributed tracing for every service	Reusable framework and build logic that handles cross-cutting concerns (logging, health, metrics, config, tracing) so each new service gets them without boilerplate

Table 2: Service Communication Patterns

Pattern	Example	Description
Synchronous Request-Response (REST)	`GET /api/users/123` returns user JSON over HTTP	• Client sends request and blocks waiting for response • simple, universal, and cacheable • creates tight temporal coupling between caller and callee

Table 3: Data Management Patterns

Pattern	Example	Description
Event Sourcing	Account history: `Created($100)` → `Deposited($50)` → `Withdrawn($30)` = $120 balance	• Stores all state changes as immutable events in append-only log • current state derived by replaying events • enables audit trail and time travel

Table 4: Service Discovery and Registry

Pattern	Example	Description
Client-Side Discovery	Client queries Consul registry, gets instance list, load balances directly	• Client queries service registry to get available instances and performs load balancing • gives client control but increases complexity