Microservices Architecture Patterns

Why This Matters

Microservices architecture patterns aren't just buzzwords for your cloud computing exam—they're the fundamental building blocks that determine whether a distributed system thrives or collapses under pressure. You're being tested on your ability to recognize when to apply each pattern, why it solves a specific problem, and how different patterns work together to create resilient, scalable systems. The exam will push you beyond simple definitions into scenarios where you must choose between competing approaches like choreography versus orchestration, or explain why a circuit breaker prevents cascading failures.

These patterns address core distributed systems challenges: communication complexity, data consistency, fault tolerance, and operational management. Understanding the underlying principles—not just the pattern names—will help you tackle FRQ scenarios where you're asked to design a solution or troubleshoot a failing architecture. Don't just memorize what each pattern does; know what problem it solves, what trade-offs it introduces, and which other patterns it pairs well with.

---

Communication and Routing Patterns

These patterns solve the fundamental challenge of how clients and services find and talk to each other. In a distributed system with dozens or hundreds of services, direct point-to-point communication becomes unmanageable—these patterns provide structure and abstraction.

API Gateway Pattern

• Single entry point for all client requests—eliminates the need for clients to know about individual service locations or protocols
• Handles cross-cutting concerns like authentication, rate limiting, logging, and SSL termination in one centralized location
• Request routing and protocol translation enable backend services to evolve independently while maintaining stable client contracts

Service Registry and Discovery Pattern

• Dynamic service registration allows instances to announce themselves at startup and deregister on shutdown—no hardcoded addresses
• Runtime discovery promotes loose coupling by letting services locate dependencies without configuration changes
• Enables load balancing and failover by maintaining real-time health status and instance counts for each service

Backend for Frontend (BFF) Pattern

• Dedicated backend per client type—mobile apps, web browsers, and IoT devices each get APIs optimized for their specific needs
• Reduces client complexity by moving data aggregation and transformation logic server-side
• Improves performance through tailored payloads that minimize over-fetching and under-fetching of data

---

Fault Tolerance and Resilience Patterns

These patterns prevent localized failures from becoming system-wide outages. The key principle: assume failure is inevitable, then design systems that degrade gracefully rather than catastrophically.

Circuit Breaker Pattern

• Monitors failure rates and "trips" when errors exceed a threshold—stops sending requests to a failing service
• Provides fallback responses such as cached data, default values, or graceful error messages during outages
• Allows recovery time by preventing overwhelmed services from receiving additional load, with automatic reset after a timeout period

Bulkhead Pattern

• Isolates resources into compartments—failure in one partition cannot exhaust resources needed by others
• Limits blast radius by ensuring a misbehaving service or tenant can only consume its allocated thread pool, connection pool, or memory
• Named after ship bulkheads that prevent a single hull breach from sinking the entire vessel—same principle, different domain

Sidecar Pattern

• Deploys helper containers alongside main services to handle logging, monitoring, security, and network proxying
• Zero code changes required—the main service remains focused on business logic while the sidecar handles infrastructure concerns
• Standardizes cross-cutting concerns across polyglot services written in different languages or frameworks

---

Data Management Patterns

Managing data across distributed services is one of the hardest problems in microservices. These patterns address the tension between service independence and data consistency.

Database per Service Pattern

• Each service owns its data exclusively—no shared databases that create hidden coupling between services
• Enables polyglot persistence where each service uses the database technology best suited to its needs (SQL, NoSQL, graph, time-series)
• Complicates cross-service queries but preserves the ability to deploy, scale, and evolve services independently

Event Sourcing Pattern

• Stores state as an immutable sequence of events rather than current values—the event log is the source of truth
• Complete audit trail enables debugging, compliance reporting, and "time travel" to reconstruct past states
• Supports complex domain logic by capturing not just what changed but why it changed, with full context preserved

CQRS (Command Query Responsibility Segregation) Pattern

• Separates read and write models—commands modify state through one path, queries retrieve data through another
• Optimizes each path independently with denormalized read replicas for fast queries and normalized write stores for consistency
• Pairs naturally with Event Sourcing where the write side captures events and the read side projects them into queryable views

---

Distributed Transaction Patterns

When operations span multiple services, traditional ACID transactions don't work. These patterns provide alternatives that maintain consistency without distributed locks.

Saga Pattern

• Breaks distributed transactions into local transactions with each service completing its step independently
• Compensating transactions undo previous steps when a later step fails—think of it as a rollback mechanism without database-level coordination
• Ensures eventual consistency rather than immediate consistency, which is the realistic goal in distributed systems

Choreography Pattern

• Decentralized event-driven coordination—each service publishes events and reacts to events from others
• No single point of failure since there's no central coordinator; services operate autonomously based on event subscriptions
• Harder to trace and debug because the workflow logic is distributed across multiple services rather than visible in one place

Orchestration Pattern

• Centralized workflow controller explicitly calls each service in sequence and handles failures
• Clear visibility into the entire process flow, making monitoring, debugging, and modification straightforward
• Single point of failure risk requires careful design of the orchestrator for high availability

---

Infrastructure and Operations Patterns

These patterns address how you deploy, configure, and manage microservices at scale. They're about operational excellence—keeping systems running smoothly as they grow.

Service Mesh Pattern

• Dedicated infrastructure layer for service-to-service communication, typically implemented as sidecar proxies (Istio, Linkerd, Consul Connect)
• Handles traffic management including load balancing, retries, timeouts, and circuit breaking without application code changes
• Provides observability and security through automatic mTLS encryption, distributed tracing, and metrics collection

Externalized Configuration Pattern

• Configuration separated from code—environment-specific settings live in external stores like Consul, etcd, or Spring Cloud Config
• Dynamic updates without redeployment allow runtime tuning of feature flags, connection strings, and operational parameters
• Centralized management ensures consistency across environments and simplifies secrets rotation

Strangler Pattern

• Incremental migration strategy that routes traffic between legacy and new systems based on functionality
• Reduces migration risk by allowing gradual cutover with easy rollback if problems emerge
• Named after strangler fig trees that grow around host trees until they can stand independently—the new system "strangles" the old one over time

---

Quick Reference Table

---

Self-Check Questions

1. Which two patterns both address fault tolerance but protect different parts of the system—one protecting downstream services and one protecting local resources?

2. Compare and contrast Choreography and Orchestration: what trade-offs would lead you to choose one over the other for a complex order fulfillment workflow?

3. A service needs to maintain a complete audit trail of all state changes and support "undo" functionality. Which pattern best addresses this requirement, and what complementary pattern would optimize read performance?

4. Your team is migrating a monolithic e-commerce application to microservices while maintaining 24/7 availability. Which pattern enables this incremental approach, and what mechanism does it use to route traffic?

5. An FRQ describes a system where a mobile app, web dashboard, and IoT device all need different data formats from the same underlying services. Which pattern would you recommend, and how does it differ from using a standard API Gateway?