Microservices Architektur mit Claude Code: Design und Implementation 2026
Microservices richtig zu schneiden ist schwer. Zu granular und du hast ein Distributed-Monolith-Problem. Zu grob und du verlierst die Vorteile. Claude Code kann als Architektur-Sparringspartner helfen — und dann auch die Services implementieren.
Wo Claude Code bei Microservices wirklich hilft
Microservices-Architektur hat zwei Phasen: Design (Service-Boundaries, Kommunikationsmuster, Datenkonsistenz) und Implementation (jeder Service als eigene Codebase). Claude Code ist in beiden stark, aber auf unterschiedliche Weise.
Design-Phase: Claude Code als Gesprächspartner — Anforderungen eintippen, Optionen diskutieren, Trade-offs abwägen. Implementation: Claude Code als Coder — Service-Boilerplate, API-Contracts, Event-Handler generieren.
Service-Boundaries definieren
Domain-Driven Design mit Claude Code
# Prompt für Service-Boundary-Analyse:
Ich baue eine E-Commerce-Plattform. Hier sind meine Anforderungen:
- Nutzer können sich registrieren und einloggen
- Produkte mit Varianten (Größe, Farbe), Preise ändern sich häufig
- Bestellungen mit Zahlungsabwicklung (Stripe)
- Lagerverwaltung: Lagerbestand pro Variante
- Email-Benachrichtigungen (Bestellbestätigung, Versand)
- Empfehlungsalgorithmus basierend auf Kaufhistorie
Schlage mir Microservices vor. Für jeden Service:
1. Verantwortlichkeit (was macht er?)
2. Eigene Datenbank? (ja/nein + warum)
3. Synchrone oder asynchrone Kommunikation?
4. Welche Events published er?
5. Welche Events konsumiert er?
TYPISCHE E-COMMERCE MICROSERVICES ARCHITEKTUR
API Gateway
↓ routes to ↓
user-service
product-service
order-service
inventory-service
↓ events via ↓
RabbitMQ / Kafka
↓ consumed by ↓
notification-service
recommendation-service
Kommunikationsmuster
| Pattern | Wann nutzen | Nachteile |
|---|---|---|
| Synchron (REST/gRPC) | Wenn die Antwort sofort benötigt wird (z.B. Produktpreis abfragen) | Kopplung, Timeout-Risiko, Kaskadenfehler |
| Asynchron (Events) | Wenn Aktionen ausgelöst werden sollen (Bestellung → Email senden) | Eventually Consistent, komplexeres Debugging |
| Saga Pattern | Verteilte Transaktionen über mehrere Services | Komplex zu implementieren, Rollback-Logik nötig |
Event-driven Communication
# Event Publishing (order-service)
# Prompt: "Implementiere Event-Publishing für OrderPlaced"
interface OrderPlacedEvent {
eventType: 'order.placed';
orderId: string;
userId: string;
items: Array<{ productId: string; quantity: number; price: number }>;
total: number;
timestamp: string;
}
class OrderService {
constructor(
private db: Database,
private eventBus: EventBus
) {}
async placeOrder(userId: string, items: OrderItem[]): Promise<Order> {
// Transaktion: DB-Schreiben + Event-Publishing atomar
return await this.db.transaction(async (trx) => {
const order = await trx.insert('orders', { userId, items, status: 'pending' });
// Outbox Pattern: Event in DB speichern für At-Least-Once Delivery
await trx.insert('event_outbox', {
eventType: 'order.placed',
payload: JSON.stringify({ orderId: order.id, userId, items, total: order.total }),
createdAt: new Date().toISOString()
});
return order;
});
}
}
Outbox Pattern: Events nicht direkt publishen — erst in DB (Outbox-Tabelle) schreiben, dann asynchron verarbeiten. Verhindert Lost Events wenn der Broker kurz down ist.
API Gateway mit Claude Code
# API Gateway Konfiguration generieren
# Prompt: "Erstelle eine Express API Gateway Konfiguration für:
# - JWT-Authentifizierung (shared secret)
# - Rate Limiting (100 req/min per IP)
# - Route zu internen Services (user:3001, product:3002, order:3003)
# - Request-Logging mit Correlation-ID"
const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const rateLimit = require('express-rate-limit');
const jwt = require('jsonwebtoken');
const { v4: uuidv4 } = require('uuid');
const app = express();
// Correlation ID für Request-Tracing
app.use((req, res, next) => {
req.correlationId = req.headers['x-correlation-id'] || uuidv4();
res.setHeader('X-Correlation-ID', req.correlationId);
next();
});
// Rate Limiting
app.use(rateLimit({ windowMs: 60000, max: 100 }));
// JWT Auth Middleware
const authenticate = (req, res, next) => {
const token = req.headers.authorization?.replace('Bearer ', '');
if (!token) return res.status(401).json({ error: 'Unauthorized' });
try {
req.user = jwt.verify(token, process.env.JWT_SECRET);
next();
} catch { res.status(401).json({ error: 'Invalid token' }); }
};
// Routes zu Services
const services = {
'/api/users': 'http://user-service:3001',
'/api/products': 'http://product-service:3002',
'/api/orders': 'http://order-service:3003',
};
Object.entries(services).forEach(([path, target]) => {
app.use(path, authenticate, createProxyMiddleware({
target,
changeOrigin: true,
on: { proxyReq: (proxyReq, req) => {
proxyReq.setHeader('X-User-ID', req.user.sub);
proxyReq.setHeader('X-Correlation-ID', req.correlationId);
}}
}));
});
Microservices sind nicht für jeden. Unter 5-10 Entwicklern ist ein gut strukturierter Monolith fast immer besser. Starte mit Monolith, identifiziere die natürlichen Seams, extrahiere Services wenn der Schmerz groß genug ist — nicht vorher.
Architektur-Modul im Kurs
Im Claude Code Mastery Kurs gibt es ein Architektur-Modul: Monolith → Microservices Migration, Event-driven Patterns, API Gateway Setup und Service-Mesh-Grundlagen — mit vollständigem Beispiel-Code.
14 Tage kostenlos testen →