Microservices Architecture & Patterns

Microservices architecture structures an application as a distributed collection of loosely coupled, independently deployable services organized around specific business domains.

1. API Gateway Pattern

An API Gateway serves as the single unified entry point for external client applications, encapsulating internal service complexity.

flowchart TD C["📱 Clients (iOS / Android / Web)"] --> GW subgraph GW["🚪 API Gateway"] direction LR Auth["JWT Validation"] SSL["SSL Termination"] RL["Rate Limiting"] Route["Request Routing"] CORS["CORS Handling"] Log["Distributed Log"] end GW --> US["👤 User Service"] GW --> OS["💳 Order Service"] GW --> PS["💰 Payment Service"]

2. Inter-Service Communication Patterns

Communication Type	Protocols / Technologies	Best Fit Scenarios
Synchronous RPC	gRPC (HTTP/2 + Protobuf), REST (HTTP/JSON)	Internal high-speed queries requiring immediate responses (e.g., Auth token verification)
Asynchronous Messaging	Apache Kafka, RabbitMQ, AWS SQS	Fire-and-forget workflows, event streaming, long-running processes

3. Circuit Breaker Pattern

The Circuit Breaker pattern prevents cascading system failures when a downstream microservice experiences downtime or severe latency spikes.

stateDiagram-v2 [*] --> CLOSED CLOSED --> OPEN : Failures exceed threshold OPEN --> HALF_OPEN : Timer expires HALF_OPEN --> CLOSED : Test request succeeded HALF_OPEN --> OPEN : Test request failed CLOSED : Requests pass normally OPEN : Fast fail (no network calls) HALF_OPEN : Send test probe requests

Closed State: Requests flow normally to the downstream service. Failures are counted.
Open State: Downstream is failing; requests fail immediately without making network calls, preventing thread pool starvation.
Half-Open State: Periodically sends a small test probe. If successful, resets to Closed; if failing, re-opens.

4. Saga Pattern (Distributed Transactions)

Because microservices maintain private databases to prevent tight coupling, traditional 2-Phase Commit (2PC) transactions across databases cause massive latency. The Saga pattern manages distributed transactions through a sequence of local transactions with compensating actions upon failure.

Example: E-Commerce Checkout Saga

flowchart TD S1["✅ Step 1: Order Service\nCreate Order (Pending)"] --> S2["✅ Step 2: Payment Service\nProcess Credit Card Charge"] S2 --> S3["❌ Step 3: Inventory Service\nReserve Stock (Out of Stock!)"] S3 -->|"🔄 Compensating Transactions"| C1["↩️ Step 4: Payment Service\nRefund Customer"] C1 --> C2["↩️ Step 5: Order Service\nMark Order: Cancelled"]

Choreography vs Orchestration:

Choreography (Event-Driven): Services emit events; next services listen and react. (Simple, but hard to trace complex flows).
Orchestration (Central Coordinator): A central orchestrator service tells each participant what step to execute next.