// Expert skill for designing, decomposing, and managing microservices architectures. Activates when users need help with microservices design, service decomposition, bounded contexts, API contracts, or transitioning from monolithic to microservices architectures.
| name | microservices-orchestrator |
| description | Expert skill for designing, decomposing, and managing microservices architectures. Activates when users need help with microservices design, service decomposition, bounded contexts, API contracts, or transitioning from monolithic to microservices architectures. |
| allowed-tools | ["Read","Write","Edit","Bash","Grep","Glob"] |
Enterprise-grade skill for designing and managing microservices architectures at scale.
This skill should be used when:
First, understand the current system architecture and requirements:
Example analysis questions:
## Architecture Analysis
### Business Domain
- What is the core business domain? (e.g., e-commerce, healthcare, fintech)
- What are the key business capabilities?
- Who are the main users and stakeholders?
### Current State
- Monolithic application or existing services?
- Current technology stack?
- Team size and structure?
- Deployment frequency and process?
### Requirements
- Expected traffic volume and growth?
- Performance requirements (latency, throughput)?
- Availability requirements (SLA)?
- Compliance requirements (HIPAA, PCI-DSS, GDPR)?
### Constraints
- Budget limitations?
- Timeline constraints?
- Technology preferences or mandates?
- Team skill levels?
Apply Domain-Driven Design to identify service boundaries:
Example bounded context mapping:
/**
* E-Commerce Platform - Bounded Contexts
*/
// 1. Product Catalog Context
interface ProductCatalogContext {
responsibilities: [
'Product information management',
'Category management',
'Search and discovery',
'Product recommendations'
];
entities: ['Product', 'Category', 'Brand', 'ProductVariant'];
services: ['ProductService', 'CategoryService', 'SearchService'];
}
// 2. Order Management Context
interface OrderManagementContext {
responsibilities: [
'Order creation and tracking',
'Order fulfillment',
'Order history',
'Returns and refunds'
];
entities: ['Order', 'OrderItem', 'Return', 'Refund'];
services: ['OrderService', 'FulfillmentService', 'ReturnService'];
}
// 3. Customer Context
interface CustomerContext {
responsibilities: [
'Customer profiles',
'Authentication',
'Preferences',
'Customer support'
];
entities: ['Customer', 'Account', 'Preference', 'SupportTicket'];
services: ['CustomerService', 'AuthService', 'PreferenceService'];
}
// 4. Payment Context
interface PaymentContext {
responsibilities: [
'Payment processing',
'Payment methods management',
'Transaction history',
'Refund processing'
];
entities: ['Payment', 'PaymentMethod', 'Transaction'];
services: ['PaymentService', 'RefundService'];
}
// 5. Inventory Context
interface InventoryContext {
responsibilities: [
'Stock management',
'Warehouse operations',
'Stock reservations',
'Inventory forecasting'
];
entities: ['InventoryItem', 'Warehouse', 'StockMovement'];
services: ['InventoryService', 'WarehouseService'];
}
Define clear API contracts for each microservice:
Example API contract:
/**
* Order Service API Contract
*/
// REST API Endpoints
interface OrderServiceAPI {
// Commands (mutations)
'POST /orders': {
request: CreateOrderRequest;
response: OrderCreated;
status: 201;
};
'PUT /orders/:id': {
request: UpdateOrderRequest;
response: OrderUpdated;
status: 200;
};
'POST /orders/:id/cancel': {
request: CancelOrderRequest;
response: OrderCancelled;
status: 200;
};
// Queries
'GET /orders/:id': {
response: OrderDetails;
status: 200;
};
'GET /orders': {
query: OrderSearchParams;
response: OrderList;
status: 200;
};
}
// Event Interfaces (Async Communication)
interface OrderServiceEvents {
// Events Published
published: [
'OrderCreated',
'OrderUpdated',
'OrderCancelled',
'OrderFulfilled'
];
// Events Consumed
consumed: [
'PaymentCompleted',
'PaymentFailed',
'InventoryReserved',
'InventoryReservationFailed'
];
}
// Data Transfer Objects
interface CreateOrderRequest {
customerId: string;
items: Array<{
productId: string;
quantity: number;
price: number;
}>;
shippingAddress: Address;
paymentMethodId: string;
}
interface OrderCreated {
orderId: string;
customerId: string;
items: OrderItem[];
totalAmount: number;
status: 'pending' | 'confirmed';
createdAt: string;
}
Determine data ownership and consistency patterns:
Example data management pattern:
/**
* Saga Pattern for Order Creation
* Ensures data consistency across Order, Payment, and Inventory services
*/
class OrderCreationSaga {
async execute(createOrderRequest: CreateOrderRequest) {
let orderId: string;
let reservationId: string;
let paymentId: string;
try {
// Step 1: Create order (pending state)
orderId = await this.orderService.createOrder({
...createOrderRequest,
status: 'pending'
});
// Step 2: Reserve inventory
reservationId = await this.inventoryService.reserveItems({
orderId,
items: createOrderRequest.items
});
// Step 3: Process payment
paymentId = await this.paymentService.processPayment({
orderId,
amount: this.calculateTotal(createOrderRequest.items),
paymentMethodId: createOrderRequest.paymentMethodId
});
// Step 4: Confirm order
await this.orderService.confirmOrder(orderId);
return { orderId, status: 'confirmed' };
} catch (error) {
// Compensating transactions (rollback)
await this.compensate({
orderId,
reservationId,
paymentId
});
throw new OrderCreationFailedError(error);
}
}
private async compensate(context: any) {
// Release inventory reservation
if (context.reservationId) {
await this.inventoryService.releaseReservation(context.reservationId);
}
// Refund payment
if (context.paymentId) {
await this.paymentService.refundPayment(context.paymentId);
}
// Cancel order
if (context.orderId) {
await this.orderService.cancelOrder(context.orderId);
}
}
}
Choose appropriate communication patterns:
Example communication design:
/**
* Communication Patterns
*/
// Synchronous - REST for direct queries
class ProductService {
@Get('/products/:id')
async getProduct(id: string): Promise<Product> {
// Direct synchronous call - fast response needed
return await this.productRepository.findById(id);
}
}
// Asynchronous - Events for loosely coupled operations
class OrderService {
async createOrder(request: CreateOrderRequest): Promise<Order> {
// Create order
const order = await this.orderRepository.create(request);
// Publish event (asynchronous - don't wait for subscribers)
await this.eventBus.publish(new OrderCreatedEvent({
orderId: order.id,
customerId: order.customerId,
items: order.items,
totalAmount: order.totalAmount
}));
return order;
}
}
// Event handlers in other services
class InventoryService {
@EventHandler(OrderCreatedEvent)
async onOrderCreated(event: OrderCreatedEvent) {
// Reserve inventory asynchronously
await this.reserveInventory(event.items);
}
}
class NotificationService {
@EventHandler(OrderCreatedEvent)
async onOrderCreated(event: OrderCreatedEvent) {
// Send order confirmation email asynchronously
await this.emailService.sendOrderConfirmation(event);
}
}
Plan deployment architecture:
Example infrastructure design:
# Kubernetes Deployment Architecture
# API Gateway
apiVersion: v1
kind: Service
metadata:
name: api-gateway
spec:
type: LoadBalancer
selector:
app: kong-gateway
ports:
- port: 80
targetPort: 8000
- port: 443
targetPort: 8443
---
# Order Service
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
spec:
replicas: 3
selector:
matchLabels:
app: order-service
template:
metadata:
labels:
app: order-service
version: v1
spec:
containers:
- name: order-service
image: myregistry/order-service:v1.0
ports:
- containerPort: 8080
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: order-db-secret
key: url
- name: KAFKA_BROKERS
value: "kafka-cluster:9092"
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
---
# Service Mesh (Istio)
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
- match:
- headers:
version:
exact: canary
route:
- destination:
host: order-service
subset: v2
weight: 10
- destination:
host: order-service
subset: v1
weight: 90
- route:
- destination:
host: order-service
subset: v1
โ Correct approach:
Scenario: Migrate monolithic e-commerce platform to microservices
Steps:
- Product Catalog (product management, search)
- Order Management (orders, fulfillment)
- Customer Management (profiles, authentication)
- Payment Processing (payments, refunds)
- Inventory Management (stock, warehouses)
- Notification (emails, SMS)
Phase 1: Extract read-heavy services
- Product Catalog (high read, low write)
- Customer Profiles (read-heavy)
Phase 2: Extract transactional services
- Order Management (ACID transactions needed)
- Payment Processing (critical path)
Phase 3: Extract supporting services
- Inventory Management
- Notification Service
// Order โ Payment: Synchronous (need immediate response)
const payment = await paymentService.processPayment({
orderId,
amount,
paymentMethod
});
// Order โ Notification: Asynchronous (fire and forget)
await eventBus.publish(new OrderCreatedEvent(order));
Scenario: Design microservices for electronic health records
Bounded Contexts:
// 1. Patient Management Service
interface PatientService {
responsibilities: [
'Patient demographics (PHI)',
'Patient registration',
'Consent management'
];
compliance: ['HIPAA', 'Audit logging', 'Encryption at rest'];
}
// 2. Clinical Data Service
interface ClinicalDataService {
responsibilities: [
'Medical records',
'Lab results',
'Prescriptions'
];
compliance: ['HIPAA', 'Access controls', 'Data retention'];
}
// 3. Appointment Service
interface AppointmentService {
responsibilities: [
'Appointment scheduling',
'Provider availability',
'Reminders'
];
}
// 4. Billing Service
interface BillingService {
responsibilities: [
'Claims processing',
'Insurance verification',
'Payment processing'
];
compliance: ['PCI-DSS for payments', 'HIPAA for claims'];
}
Security Architecture:
// Zero-trust security model
class ServiceAuthMiddleware {
async authenticate(request: Request) {
// 1. Verify JWT token
const token = this.extractToken(request);
const claims = await this.jwtService.verify(token);
// 2. Verify service identity (mTLS)
const clientCert = request.socket.getPeerCertificate();
await this.verifyCertificate(clientCert);
// 3. Check access control (RBAC)
const hasAccess = await this.rbacService.checkPermission(
claims.userId,
request.path,
request.method
);
if (!hasAccess) {
throw new ForbiddenError('Access denied');
}
// 4. Audit log
await this.auditService.log({
userId: claims.userId,
action: `${request.method} ${request.path}`,
timestamp: new Date(),
ipAddress: request.ip
});
return claims;
}
}
service-mesh-integrator - Configure Istio/Linkerdapi-gateway-configurator - Set up Kong/Tykevent-driven-architect - Design event-driven systemsdistributed-tracing-setup - Configure Jaeger/Zipkin/dependency-graph - Visualize service dependencies/adr-create - Document architecture decisions/load-test-suite - Test microservices performanceenterprise-architect - High-level system designdistributed-systems-architect - Deep microservices expertisesre-consultant - Reliability and monitoringWhen to Use Microservices:
When NOT to Use Microservices:
Migration Strategy:
Success Metrics: