Alle Projekte
Coding Challenge

WIT — Verteilter Rechner

2025·Einzelprojekt
KafkaPythonDockerREST API

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

EbeneTechnologieWarum
MessagingKafkaPartitionierung, Dauerhaftigkeit, Replay
ServicesPython-MicroservicesSchnelle Iteration, gut lesbar
OrchestrierungDocker ComposeReproduzierbarer lokaler Cluster
EinstiegspunktREST-GatewayVertraute 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.