Remember our LEGO castle from the monolith lesson? A microservices architecture is like building your castle from many small, independent pieces that work together but can be changed, moved, or replaced individually.
Each piece (microservice) has one specific job:
If the drawbridge breaks, the kitchen still works!
Companies like Netflix, Uber, Amazon, and Spotify run on microservices architectures with hundreds or thousands of services. But they didn’t start that way - they evolved to microservices when their monoliths couldn’t scale anymore.
Each microservice should do one thing well.
Bad Example:
OrdersAndPaymentsAndShippingService├── Process orders├── Handle payments├── Manage shipping└── Send notificationsGood Example:
OrderService → Manages orders onlyPaymentService → Handles payments onlyShippingService → Manages shipping onlyNotificationService → Sends notifications onlyDeploy one service without touching others.
# Deploy only the payment servicekubectl apply -f payment-service-v2.yaml
# Order service keeps running with no downtime# User service keeps running with no downtimeEach service has its own database. No shared databases!
Each team owns their service end-to-end:
Example:
Scale only what needs scaling!
Use the right tool for the job!
Real-World Example: Netflix
Each team chooses what works best for their problem domain.
One service failure doesn’t bring down the entire system.
With graceful degradation:
Teams can work independently without stepping on each other’s toes.
| Aspect | Monolith | Microservices |
|---|---|---|
| Deployment | Coordinate with everyone | Deploy independently |
| Technology | Everyone uses same stack | Choose your own stack |
| Database | Shared, coordinate schema changes | Own your schema |
| Testing | Wait for full integration tests | Test your service in isolation |
| Ownership | Blurred boundaries | Clear ownership |
Instead of understanding a 1M line monolith, understand a 10K line service.
Cognitive Load:
New engineers can become productive faster on individual services.
# In a monolith - this ALWAYS works or throws exceptionpayment_result = payment_service.process(order)
# In microservices - this can fail in many ways:try: response = http.post('http://payment-service/process', json=order, timeout=5) # What if: # - Network is down? # - Payment service is down? # - Request times out? # - Response is corrupted? # - Payment processed but response lost?except RequestTimeout: # Did the payment process or not? 🤷 # This is the "Two Generals Problem" passNo more ACID transactions across services!
# One database transaction - ACID guaranteed@transactionaldef create_order(user_id, items, payment_info): # All succeed or all fail atomically order = order_repo.save(Order(user_id, items)) payment = payment_repo.save(Payment(order.id, payment_info)) inventory_repo.reserve(items) return order# Three service calls - no atomic transaction!def create_order(user_id, items, payment_info): # Step 1: Create order order = order_service.create(user_id, items)
# Step 2: Process payment (different service/database) try: payment = payment_service.process(order.id, payment_info) except PaymentFailed: # Need to compensate - cancel the order order_service.cancel(order.id) raise
# Step 3: Reserve inventory (different service/database) try: inventory_service.reserve(order.id, items) except InsufficientStock: # Need to compensate both previous operations! payment_service.refund(payment.id) order_service.cancel(order.id) raise
# What if the service crashes here? 😱 # Order created, payment processed, but inventory not reserved!Solution: Saga Pattern, eventual consistency (covered in async patterns section)
Challenges:
| Task | Monolith | 10 Microservices | 100 Microservices |
|---|---|---|---|
| Deployment pipeline | 1 | 10 | 100 |
| Monitoring dashboards | 1 | 10 | 100 |
| Log aggregation | 1 source | 10 sources | 100 sources |
| Databases to manage | 1 | 10 | 100 |
| Security patches | 1 app | 10 apps | 100 apps |
| Incident response | 1 service down | Which of 10? | Which of 100? |
Required Infrastructure:
Scenario: User reports “checkout is slow”
In a Monolith:
Check logs → Find slow database query → FixTime: 10 minutesIn Microservices:
Check which service is slow → API Gateway logs→ Order Service logs → Payment Service logs→ Inventory Service logs → User Service logs→ Find slow service → Check its dependencies→ Distributed trace shows: Payment Service calling external API slowlyTime: 2 hours (and a lot of frustration)Performance Comparison:
Large, Mature Organization
Proven Product with Clear Boundaries
Different Scaling Requirements
Team Autonomy is Critical
You Have the Infrastructure and Expertise
Starting a New Product
Small Team (< 20 engineers)
Strong Consistency Requirements
Limited DevOps Capabilities
Group by business capabilities, not technical layers.
Bad (Technical Boundaries):
UserServiceProductServiceDatabaseServiceNotificationServiceGood (Business Boundaries):
OrderManagement → Everything about ordersInventoryManagement → Everything about inventoryCustomerManagement → Everything about customersPaymentProcessing → Everything about paymentsEach service represents a bounded context with its own:
Key Insight: The same entity can have different representations in different contexts!
import httpxfrom typing import Optional
class OrderService: def __init__(self, payment_client: 'PaymentClient'): self._payment_client = payment_client
async def create_order(self, user_id: str, items: list) -> Order: # Create order order = Order(user_id=user_id, items=items) await self._order_repo.save(order)
# Synchronous call to payment service try: payment_result = await self._payment_client.process_payment( order_id=order.id, amount=order.total, timeout=5.0 # Always set timeouts! )
if payment_result.status == 'success': order.mark_as_paid() else: order.mark_as_failed()
except httpx.TimeoutException: # Handle timeout - what should we do? order.mark_as_pending_payment() # Maybe retry later via background job
return order
class PaymentClient: """Client for calling Payment Service"""
def __init__(self, base_url: str): self._base_url = base_url self._client = httpx.AsyncClient()
async def process_payment( self, order_id: str, amount: float, timeout: float ) -> PaymentResult: response = await self._client.post( f"{self._base_url}/payments", json={"order_id": order_id, "amount": amount}, timeout=timeout ) response.raise_for_status() return PaymentResult(**response.json())public class OrderService { private final PaymentClient paymentClient; private final OrderRepository orderRepo;
public Order createOrder(String userId, List<Item> items) { // Create order Order order = new Order(userId, items); orderRepo.save(order);
// Synchronous call to payment service try { PaymentResult result = paymentClient.processPayment( order.getId(), order.getTotal(), Duration.ofSeconds(5) // Always set timeouts! );
if (result.getStatus() == PaymentStatus.SUCCESS) { order.markAsPaid(); } else { order.markAsFailed(); }
} catch (TimeoutException e) { // Handle timeout - what should we do? order.markAsPendingPayment(); // Maybe retry later via background job }
return order; }}
public interface PaymentClient { PaymentResult processPayment( String orderId, BigDecimal amount, Duration timeout ) throws TimeoutException;}
public class HttpPaymentClient implements PaymentClient { private final HttpClient httpClient; private final String baseUrl;
@Override public PaymentResult processPayment( String orderId, BigDecimal amount, Duration timeout ) { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/payments")) .timeout(timeout) .POST(BodyPublishers.ofString( String.format("{\"order_id\":\"%s\",\"amount\":%s}", orderId, amount) )) .build();
HttpResponse<String> response = httpClient.send( request, HttpResponse.BodyHandlers.ofString() );
return parsePaymentResult(response.body()); }}Pros:
Cons:
from dataclasses import dataclassimport asyncio
@dataclassclass OrderCreatedEvent: order_id: str user_id: str total: float timestamp: datetime
class OrderService: def __init__(self, message_broker: 'MessageBroker'): self._broker = message_broker
async def create_order(self, user_id: str, items: list) -> Order: # Create order order = Order(user_id=user_id, items=items) await self._order_repo.save(order)
# Publish event asynchronously await self._broker.publish( topic='order.created', event=OrderCreatedEvent( order_id=order.id, user_id=user_id, total=order.total, timestamp=datetime.now() ) )
# Don't wait for payment processing! # Payment service will consume event and process asynchronously return order
class PaymentService: """Separate service that consumes events"""
def __init__(self, message_broker: 'MessageBroker'): self._broker = message_broker # Subscribe to order events self._broker.subscribe('order.created', self.handle_order_created)
async def handle_order_created(self, event: OrderCreatedEvent): """Process payment asynchronously""" try: result = await self._process_payment( event.order_id, event.total )
# Publish result event await self._broker.publish( topic='payment.processed', event=PaymentProcessedEvent( order_id=event.order_id, status=result.status ) ) except Exception as e: # Handle error - maybe retry or dead-letter await self._broker.publish( topic='payment.failed', event=PaymentFailedEvent( order_id=event.order_id, error=str(e) ) )public record OrderCreatedEvent( String orderId, String userId, BigDecimal total, Instant timestamp) {}
public class OrderService { private final MessageBroker broker; private final OrderRepository orderRepo;
public Order createOrder(String userId, List<Item> items) { // Create order Order order = new Order(userId, items); orderRepo.save(order);
// Publish event asynchronously broker.publish( "order.created", new OrderCreatedEvent( order.getId(), userId, order.getTotal(), Instant.now() ) );
// Don't wait for payment processing! // Payment service will consume event and process asynchronously return order; }}
@Servicepublic class PaymentService { private final MessageBroker broker;
public PaymentService(MessageBroker broker) { this.broker = broker; // Subscribe to order events broker.subscribe("order.created", this::handleOrderCreated); }
public void handleOrderCreated(OrderCreatedEvent event) { try { PaymentResult result = processPayment( event.orderId(), event.total() );
// Publish result event broker.publish( "payment.processed", new PaymentProcessedEvent( event.orderId(), result.getStatus() ) ); } catch (Exception e) { // Handle error - maybe retry or dead-letter broker.publish( "payment.failed", new PaymentFailedEvent( event.orderId(), e.getMessage() ) ); } }}Pros:
Cons:
Scale:
Evolution:
Key Practices:
Architecture:
Challenges They Faced:
Service discovery at scale
Cascading failures
Debugging distributed traces
The Mandate (2002):
“All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed. Anyone who doesn’t do this will be fired.” - Jeff Bezos
Result:
from enum import Enumfrom pydantic import BaseModel
class ApiVersion(Enum): V1 = "v1" V2 = "v2"
# V1 API - originalclass OrderV1(BaseModel): id: str user_id: str total: float
# V2 API - added items fieldclass OrderV2(BaseModel): id: str user_id: str items: list[Item] total: float tax: float # Breaking change!
# Support both versions@app.get("/api/v1/orders/{order_id}")async def get_order_v1(order_id: str) -> OrderV1: order = await order_repo.get(order_id) return OrderV1( id=order.id, user_id=order.user_id, total=order.total )
@app.get("/api/v2/orders/{order_id}")async def get_order_v2(order_id: str) -> OrderV2: order = await order_repo.get(order_id) return OrderV2( id=order.id, user_id=order.user_id, items=order.items, total=order.total, tax=order.tax )// V1 API - originalpublic record OrderV1( String id, String userId, BigDecimal total) {}
// V2 API - added items fieldpublic record OrderV2( String id, String userId, List<Item> items, BigDecimal total, BigDecimal tax // Breaking change!) {}
@RestControllerpublic class OrderController {
// Support both versions @GetMapping("/api/v1/orders/{orderId}") public OrderV1 getOrderV1(@PathVariable String orderId) { Order order = orderRepo.findById(orderId); return new OrderV1( order.getId(), order.getUserId(), order.getTotal() ); }
@GetMapping("/api/v2/orders/{orderId}") public OrderV2 getOrderV2(@PathVariable String orderId) { Order order = orderRepo.findById(orderId); return new OrderV2( order.getId(), order.getUserId(), order.getItems(), order.getTotal(), order.getTax() ); }}Every service should expose health endpoints:
@app.get("/health/live")async def liveness(): """Is the service running?""" return {"status": "ok"}
@app.get("/health/ready")async def readiness(): """Is the service ready to accept traffic?""" # Check database connection if not await database.is_connected(): raise HTTPException(status_code=503, detail="Database not ready")
# Check dependent services if not await payment_service.is_available(): raise HTTPException(status_code=503, detail="Payment service unavailable")
return {"status": "ready"}Structured Logging:
import structlog
logger = structlog.get_logger()
async def create_order(order_id: str, user_id: str): logger.info( "order.create.started", order_id=order_id, user_id=user_id, service="order-service" )
# ... business logic ...
logger.info( "order.create.completed", order_id=order_id, duration_ms=duration, service="order-service" )Distributed Tracing:
from opentelemetry import trace
tracer = trace.get_tracer(__name__)
async def create_order(order_id: str): with tracer.start_as_current_span("order.create") as span: span.set_attribute("order.id", order_id)
# Call payment service - trace continues! with tracer.start_as_current_span("payment.process"): await payment_client.process(order_id)Prevent cascading failures:
from enum import Enumimport asyncio
class CircuitState(Enum): CLOSED = "closed" # Normal operation OPEN = "open" # Failing, reject requests HALF_OPEN = "half_open" # Testing if recovered
class CircuitBreaker: def __init__(self, failure_threshold: int = 5, timeout: int = 60): self.failure_threshold = failure_threshold self.timeout = timeout self.failure_count = 0 self.last_failure_time = None self.state = CircuitState.CLOSED
async def call(self, func, *args, **kwargs): if self.state == CircuitState.OPEN: # Check if timeout expired if time.time() - self.last_failure_time > self.timeout: self.state = CircuitState.HALF_OPEN else: raise CircuitOpenError("Circuit breaker is OPEN")
try: result = await func(*args, **kwargs) self._on_success() return result except Exception as e: self._on_failure() raise
def _on_success(self): self.failure_count = 0 self.state = CircuitState.CLOSED
def _on_failure(self): self.failure_count += 1 self.last_failure_time = time.time()
if self.failure_count >= self.failure_threshold: self.state = CircuitState.OPEN
# Usagepayment_breaker = CircuitBreaker()
async def call_payment_service(order_id): try: return await payment_breaker.call( payment_client.process, order_id ) except CircuitOpenError: # Fallback: queue for later processing await queue.enqueue(order_id) return {"status": "queued"}public enum CircuitState { CLOSED, // Normal operation OPEN, // Failing, reject requests HALF_OPEN // Testing if recovered}
public class CircuitBreaker { private final int failureThreshold; private final long timeout; private int failureCount = 0; private long lastFailureTime = 0; private CircuitState state = CircuitState.CLOSED;
public <T> T call(Supplier<T> supplier) throws CircuitOpenException { if (state == CircuitState.OPEN) { if (System.currentTimeMillis() - lastFailureTime > timeout) { state = CircuitState.HALF_OPEN; } else { throw new CircuitOpenException("Circuit breaker is OPEN"); } }
try { T result = supplier.get(); onSuccess(); return result; } catch (Exception e) { onFailure(); throw e; } }
private void onSuccess() { failureCount = 0; state = CircuitState.CLOSED; }
private void onFailure() { failureCount++; lastFailureTime = System.currentTimeMillis();
if (failureCount >= failureThreshold) { state = CircuitState.OPEN; } }}
// UsageCircuitBreaker paymentBreaker = new CircuitBreaker(5, 60000);
public PaymentResult callPaymentService(String orderId) { try { return paymentBreaker.call(() -> paymentClient.process(orderId) ); } catch (CircuitOpenException e) { // Fallback: queue for later processing queue.enqueue(orderId); return new PaymentResult("queued"); }}Start with Monolith
Don’t start with microservices. Prove your product first, then evolve architecture based on real constraints.
Trade-offs Matter
Microservices trade code complexity for operational complexity. Be prepared for distributed system challenges.
Team Size Matters
Microservices work best with large teams (50+). Small teams benefit more from well-designed monoliths.
Boundaries are Hard
Finding the right service boundaries is hard. Use Domain-Driven Design principles to guide decomposition.