microservices

Microservices Patterns

Design and implementation patterns for decomposing monoliths and building reliable distributed backend systems.

When to Activate

• Decomposing a monolith into services or defining service boundaries
• Choosing between synchronous (REST/gRPC) and asynchronous (messaging) communication
• Implementing resilience patterns: circuit breaker, retry, bulkhead, timeout
• Designing data ownership and cross-service transactions (Saga, CQRS)
• Setting up an API gateway or BFF for client-facing traffic
• Designing for eventual consistency or event-driven workflows
• Debugging distributed failures, cascading errors, or data inconsistency

Service Decomposition

Decomposition Strategies

Strategy	Approach	Best For
By domain (DDD)	Align services to bounded contexts	Greenfield, domain-rich systems
By subdomain	Core / supporting / generic subdomains	Prioritising build-vs-buy
Strangler fig	Incrementally replace monolith routes	Existing monoliths
By volatility	Isolate frequently-changing logic	High-churn business rules

Bounded Context Rules

# BAD: Shared User model across services
OrderService   → reads User.loyaltyPoints
PaymentService → reads User.billingAddress
EmailService   → reads User.email

# GOOD: Each service owns what it needs
OrderService   → owns OrderCustomer { id, name, loyaltyPoints }
PaymentService → owns PaymentProfile { userId, billingAddress, paymentMethods }
EmailService   → owns ContactRecord { userId, email, preferences }

Each service owns its data. No direct cross-service DB queries.

Strangler Fig Migration

1. Route all traffic through a facade (nginx / API gateway)
2. Identify one vertical slice (e.g., /api/payments/*)
3. Implement that slice as a new service
4. Re-route the facade to the new service
5. Delete the monolith code for that slice
6. Repeat — monolith shrinks, services grow

Inter-Service Communication

Sync vs Async Decision