WIT — Verteilter Rechner
Rechner auf Basis von Microservices, entwickelt als technische Aufgabe, mit Fokus auf asynchrones Messaging und Service-Orchestrierung.
Die Aufgabe
Einen Rechner bauen. Der Haken: Die Arbeit sollte auf mehrere Services verteilt werden, die asynchron kommunizieren. Es geht nicht um die Mathematik — sondern darum, ob man in den Grundbausteinen verteilter Systeme denken kann.
Architektur
Eine kleine Gruppe von Services, die Rechenanfragen über einen Message Bus weiterreichen, sie unabhängig verarbeiten und die Ergebnisse ohne enge Kopplung zurückgeben.
Client
↓
API Gateway → Kafka-Topic: requests
↓
Worker-Services (konsumieren, rechnen, publizieren)
↓
Kafka-Topic: results
↓
API Gateway
↓
Client
Wichtige Entscheidungen
Kafka, nicht RabbitMQ oder Redis Streams. Die Aufgabe verlangte asynchrones Messaging im grossen Massstab — Kafka ist die klassische Wahl, wenn man Parallelität über Partitionen und dauerhaftes Replay will. RabbitMQ wäre einfacher gewesen, aber dem Problem weniger gerecht geworden.
Zustandslose Worker. Die Worker teilen keinen Speicher und hängen nicht voneinander ab. Mehr Kapazität bedeutet docker-compose up --scale worker=N. Genau darum geht es bei dieser Architektur — nicht um die Berechnung.
Idempotente Verarbeitung. Jede Anfrage trägt eine UUID. Die Worker prüfen sie vor der Berechnung, damit Wiederholungen durch den Broker nicht doppelt verarbeitet werden. Am Anfang günstig umzusetzen, später teuer.
Keine Persistenzschicht. Die Aufgabe verlangte keine. Ich habe bewusst darauf verzichtet — den Umfang einer technischen Aufgabe auszuweiten, ist selbst ein Warnsignal.
Begründung des Stacks
| Ebene | Technologie | Warum |
|---|---|---|
| Messaging | Kafka | Partitionierung, Dauerhaftigkeit, Replay |
| Services | Python-Microservices | Schnelle Iteration, gut lesbar |
| Orchestrierung | Docker Compose | Reproduzierbarer lokaler Cluster |
| Einstiegspunkt | REST-Gateway | Vertraute Schnittstelle für Clients |
Rückblick
Was ich für den Produktivbetrieb ergänzen würde: eine Dead-Letter-Queue für fehlerhafte Nachrichten, Observability mit OpenTelemetry, eine Schema Registry für die Kafka-Payloads und einen Circuit Breaker im Gateway. Das Grundgerüst stimmt — das sind betriebliche Härtungen, keine Architekturänderungen.