Microservices

Microservices ist ein Architekturansatz, bei dem eine Anwendung als Sammlung kleiner, unabhängiger Services strukturiert wird. Jeder Service hat eine klar definierte Aufgabe (User-Management, Bestellungen, Zahlungen), eine eigene Datenbank und kommuniziert über APIs mit anderen Services. Im Gegensatz zum Monolithen (eine große Anwendung) können Microservices unabhängig entwickelt, getestet und deployed werden.

Die Vorteile bei großen Systemen: Teams können parallel an verschiedenen Services arbeiten, technologie-unabhängig (Service A in Node.js, Service B in Go), einzelne Services bei Last skalieren und Ausfälle isolieren (ein fehlerhafter Service bringt nicht alles zum Absturz). Netflix, Amazon und Uber sind bekannte Microservices-Anwender.

Die Nachteile sind erheblich: Verteilte Systeme sind komplex (Netzwerk-Latenz, Datenkonsistenz), Debugging über Service-Grenzen schwierig, Infrastruktur-Overhead durch Service-Discovery, Load-Balancing und Monitoring. Für kleine Teams und Projekte sind Microservices Overkill - ein gut strukturierter Monolith ist oft besser. Microservices lohnen sich erst bei großen Teams (50+ Entwickler) oder spezifischen Skalierungsanforderungen.

Die Kommunikation zwischen Services erfolgt entweder synchron (REST oder gRPC, wobei der Aufrufer auf die Antwort wartet) oder asynchron über einen Message-Broker wie RabbitMQ oder Apache Kafka, bei dem Events entkoppelt in Queues landen - Letzteres erhöht die Resilienz, weil ein kurzzeitig ausgefallener Service Nachrichten später abarbeiten kann. Ein API-Gateway bündelt die Services nach außen zu einer Schnittstelle und übernimmt Authentifizierung sowie Rate-Limiting; Service-Discovery und Load-Balancing sorgen dafür, dass Instanzen sich dynamisch finden.

Die größte Herausforderung ist die Datenkonsistenz: Weil jeder Service seine eigene Datenbank besitzt, gibt es keine übergreifenden Transaktionen - stattdessen kommen Muster wie das Saga-Pattern (verkettete, kompensierbare Teilschritte) und Eventual Consistency zum Einsatz. Um kaskadierende Ausfälle zu verhindern, kapselt man Aufrufe in Circuit Breaker, die einen überlasteten Service temporär abklemmen. Dieser Aufwand - verteiltes Tracing, zentrales Logging, Container-Orchestrierung - lohnt sich erst ab einer gewissen Organisationsgröße. Für die meisten Projekte ist der Modular-Monolith-First-Ansatz ratsam: eine sauber in Module getrennte, aber gemeinsam deploybare Anwendung, die sich bei echtem Bedarf gezielt in Services zerlegen lässt. Microservices sind eine Antwort auf ein Organisations- und Skalierungsproblem, nicht per se die modernere Architektur.