Why This Matters
Microservices architecture is foundational to modern DevOps practice—it's the structural pattern that makes continuous integration and deployment actually work at scale. When you're tested on CI/CD pipelines, container orchestration, or system reliability, you're really being tested on how well you understand the principles behind breaking monolithic applications into independent, deployable services. These concepts show up everywhere: in interview questions about system design, in troubleshooting scenarios, and in architectural decision-making.
The concepts here demonstrate core principles like loose coupling, fault isolation, independent deployability, and observability. Don't just memorize that "Kubernetes does orchestration"—understand why containerization enables microservices, how service discovery solves the problem of dynamic environments, and when to choose synchronous versus asynchronous communication. That conceptual understanding is what separates someone who can pass an exam from someone who can actually build resilient systems.
Architectural Foundations
These patterns define how microservices are structured and how they relate to each other. The core principle is decomposition—breaking complex systems into manageable, independent units that can evolve separately.
Service-Oriented Architecture (SOA)
- Loosely coupled services—the foundational design philosophy where each service operates independently with well-defined interfaces
- Reusability and interoperability allow services to be shared across applications and integrated with third-party systems
- Predecessor to microservices that established key principles; microservices take SOA further with smaller, more focused service boundaries
Database per Service
- Data encapsulation—each microservice owns its data exclusively, preventing direct database access from other services
- Technology flexibility means teams can choose the best database type (relational, document, graph) for each service's specific needs
- Autonomy trade-off reduces coupling but introduces challenges around data consistency and cross-service queries
CQRS (Command Query Responsibility Segregation)
- Separates read and write operations into distinct models, allowing each to be optimized independently
- Independent scaling lets you add read replicas without affecting write performance, critical for read-heavy applications
- Complex but powerful—pairs naturally with event sourcing and is essential for high-performance microservices architectures
Compare: Database per Service vs. CQRS—both address data management but at different levels. Database per service is about ownership boundaries between services, while CQRS is about optimizing operations within a service. FRQ tip: if asked about scaling read-heavy workloads, CQRS is your answer; if asked about service autonomy, database per service is the concept.
Communication Patterns
How services talk to each other determines system resilience and performance. The key trade-off is between tight coupling (simpler, real-time) and loose coupling (more complex, more resilient).
API Gateway Pattern
- Single entry point for all client requests, simplifying client-side logic and hiding internal service topology
- Cross-cutting concerns like authentication, rate limiting, SSL termination, and logging are handled in one place
- Request routing and composition can aggregate responses from multiple services into a single client response
Microservices Communication Patterns
- Synchronous communication (REST, gRPC) provides real-time responses but creates temporal coupling—if the downstream service is down, the request fails
- Asynchronous communication (message queues, event streams) decouples services in time, improving resilience at the cost of complexity
- Pattern selection depends on whether you need immediate consistency (synchronous) or can tolerate eventual consistency (asynchronous)
Event-Driven Architecture
- Services communicate through events rather than direct calls, enabling true decoupling between producers and consumers
- Scalability and responsiveness improve because services don't wait for responses; they react to events as they arrive
- Real-time processing supports complex event handling, stream processing, and reactive system designs
Compare: Synchronous (REST/gRPC) vs. Asynchronous (Event-Driven)—synchronous is simpler to implement and debug but creates brittle dependencies; asynchronous is more resilient but requires careful handling of eventual consistency. If an FRQ asks about building a fault-tolerant order processing system, event-driven architecture is your go-to example.
Resilience and Reliability
These patterns prevent failures from cascading and keep systems running when things go wrong. The principle here is fault isolation—containing failures so they don't bring down the entire system.
Circuit Breaker Pattern
- Prevents cascading failures by monitoring service calls and "opening" the circuit when failure rates exceed a threshold
- Three states: closed (normal operation), open (failing fast), and half-open (testing if service recovered)
- Fallback mechanisms provide degraded functionality rather than complete failure, maintaining user experience
Saga Pattern for Distributed Transactions
- Manages distributed transactions through a sequence of local transactions, each with a compensating action if something fails
- Two coordination approaches: choreography (services react to events) and orchestration (central coordinator directs the flow)
- Eventual consistency replaces ACID transactions; critical for maintaining data integrity across service boundaries
Service Discovery
- Dynamic service registration automatically tracks which service instances are available and where they're running
- Enables elastic scaling—new instances register themselves, failed instances are removed from the registry
- Client-side vs. server-side discovery determines whether clients or load balancers query the registry
Compare: Circuit Breaker vs. Saga Pattern—both handle failure scenarios but at different scopes. Circuit breaker prevents a single failing service from overwhelming the system; saga pattern ensures data consistency when a multi-step business process partially fails. Know when to apply each: circuit breaker for service calls, saga for business transactions.
Infrastructure and Deployment
These technologies make microservices practical to deploy and manage. The core principle is abstraction—hiding infrastructure complexity so teams can focus on service logic.
Containerization (Docker)
- Packages application + dependencies into lightweight, portable units that run consistently across any environment
- Isolation without VM overhead—containers share the host OS kernel, making them faster to start and more resource-efficient
- Immutable deployments ensure what you test in staging is exactly what runs in production
Orchestration (Kubernetes)
- Automates container lifecycle including deployment, scaling, load balancing, and self-healing
- Declarative configuration lets you define desired state; Kubernetes continuously works to maintain it
- Service discovery and networking are built-in, solving core microservices challenges at the platform level
Load Balancing
- Distributes traffic across multiple service instances to prevent any single instance from becoming a bottleneck
- Multiple implementation levels: client-side (service mesh), server-side (reverse proxy), or dedicated hardware/software load balancers
- Health-aware routing directs traffic only to healthy instances, improving availability
Compare: Containerization vs. Orchestration—Docker solves the "works on my machine" problem by packaging applications; Kubernetes solves the "how do I run 100 containers reliably" problem by managing them. You need both: containers without orchestration don't scale; orchestration without containers has nothing to orchestrate.
Observability and Operations
These practices provide visibility into distributed systems. The principle is that you can't fix what you can't see—microservices require sophisticated monitoring because failures can occur anywhere.
Distributed Tracing
- Tracks requests across service boundaries by propagating correlation IDs through the entire request path
- Identifies latency bottlenecks by showing exactly where time is spent as requests flow through the system
- Essential for debugging in microservices where a single user action might touch dozens of services
Centralized Logging
- Aggregates logs from all services into a searchable, unified platform (ELK stack, Splunk, etc.)
- Correlation across services lets you follow a single transaction through multiple log streams
- Compliance and auditing requirements often mandate centralized, immutable log retention
Service Mesh
- Dedicated infrastructure layer for service-to-service communication, typically implemented as sidecar proxies
- Zero-code observability provides metrics, tracing, and logging without modifying application code
- Advanced traffic management enables canary deployments, A/B testing, and fine-grained routing policies
Compare: Distributed Tracing vs. Centralized Logging—both provide observability but serve different purposes. Logging captures what happened within each service; tracing shows how requests flow between services. Use logging for debugging individual service behavior; use tracing for understanding system-wide performance and dependencies.
Quick Reference Table
|
| Architectural Decomposition | SOA, Database per Service, CQRS |
| Service Communication | API Gateway, Event-Driven Architecture, Sync/Async Patterns |
| Fault Tolerance | Circuit Breaker, Saga Pattern, Service Discovery |
| Container Infrastructure | Docker (containerization), Kubernetes (orchestration) |
| Traffic Management | Load Balancing, API Gateway, Service Mesh |
| Observability | Distributed Tracing, Centralized Logging, Service Mesh |
| Data Consistency | Saga Pattern, CQRS, Database per Service |
| Deployment Automation | Kubernetes, Containerization, Service Discovery |
Self-Check Questions
-
Compare and contrast the Circuit Breaker pattern and the Saga pattern. In what scenarios would you use each, and why can't one replace the other?
-
Which two concepts both address the challenge of managing data in microservices, but at different architectural levels? Explain what problem each solves.
-
If you needed to debug why a user's checkout request is taking 10 seconds, which observability tool would you use first—centralized logging or distributed tracing? Justify your choice.
-
A team is deciding between REST APIs and message queues for communication between their order service and inventory service. What factors should drive this decision, and what trade-offs does each approach involve?
-
FRQ-style prompt: Explain how containerization (Docker) and orchestration (Kubernetes) work together to enable microservices deployment. Why is neither sufficient on its own for production systems?