Monolith vs Microservices: Wie man seine Architektur 2026 waehlt

Fast ein Jahrzehnt lang war die vorherrschende Meinung in der Softwarearchitektur einfach: Microservices sind die Zukunft, Monolithen sind Legacy. Wenn man ein neues Projekt startete, baute man Microservices. Wenn man einen bestehenden Monolithen hatte, plante man dessen Zerlegung. Die Frage war nicht, ob man Microservices einfuehren sollte, sondern wie schnell man dorthin kommen konnte.

Dieser Konsens ist tot. Die letzten drei Jahre haben eine Welle von Nachbetrachtungen von Teams hervorgebracht, die Microservices zu frueh, zu aggressiv oder aus den falschen Gruenden eingefuehrt haben. Das Prime-Video-Team von Amazon veroefentlichte eine Fallstudie, die zeigte, dass der Wechsel von serverlosen Microservices zu einem Monolithen die Kosten um 90 % senkte. InnoGames berichtete von einer Halbierung der Infrastrukturkomplexitaet durch die Konsolidierung von Microservices zurueck in einen Monolithen. Diese Geschichten sind keine Ausnahmen - sie sind die Spitze einer Korrekturbewegung.

Dieser Artikel ist kein Plaedoyer fuer die eine oder andere Architektur. Es ist ein Entscheidungsrahmen fuer die Wahl zwischen beiden, geschrieben fuer 2026, mit dem Vorteil, einen vollstaendigen Zyklus von Hype und Ernuechterung miterlebt zu haben. Am Ende sollten Sie genau wissen, welche Fragen Sie stellen muessen, bevor Sie Ihre naechste Architektur waehlen.

Das Pendel hat zurueckgeschwungen

Das urspruengliche Versprechen von Microservices war verfuehrerisch: unabhaengige Bereitstellbarkeit, Teamautonomie, polyglotte Technologie-Stacks und horizontale Skalierbarkeit. Jeder Dienst konnte von einem kleinen Team entwickelt, getestet und bereitgestellt werden, ohne mit anderen abzustimmen. Wenn ein Dienst ausfiel, brachte er nicht das gesamte System zum Absturz. Wenn ein Dienst skaliert werden musste, skalierte man nur diesen Dienst.

Diese Vorteile sind real, aber sie haben einen Preis, der in den Hype-Jahren systematisch heruntergespielt wurde. Jeder Microservice fuehrt Netzwerklatenz, Komplexitaet verteilter Systeme, Herausforderungen bei der Datenkonsistenz und operativen Overhead ein. Ein Monolith hat eine Deployment-Pipeline, eine zu ueberwachende Anwendung, eine zu verwaltende Datenbank und eine zu navigierende Codebasis. Zehn Microservices haben zehn von allem, multipliziert mit den Integrationspunkten zwischen ihnen.

Die grundlegende Erkenntnis, die die Branche wiederentdeckt hat, ist, dass Microservices ein Kostenfaktor sind, kein Nutzen. Sie sind ein Werkzeug zur Verwaltung spezifischer Einschraenkungen - Teamgroesse, Skalierungsanforderungen, Deployment-Haeufigkeit -, nicht ein Endzustand, den jedes System anstreben sollte. Wenn Sie nicht das Problem haben, das Microservices loesen, machen sie Ihr System nicht besser. Sie machen es teurer und schwerer aenderbar.

Microservices sind eine gute Loesung fuer eine bestimmte Reihe von Problemen. Wenn Sie diese Probleme nicht haben, zahlen Sie die Kosten fuer Microservices, ohne den Nutzen zu erhalten. Die teuerste Architektur ist die, die Probleme loest, die Sie nicht haben.

Die Landschaft von 2026 spiegelt diese Korrektur wider. Reine Microservices-Architekturen konzentrieren sich jetzt auf Organisationen, die sie wirklich brauchen - grosse Engineering-Organisationen mit Dutzenden von Teams, Plattformen, die unabhaengige Skalierung verschiedener Komponenten benoetigen, und Produkte, bei denen verschiedene Dienste grundlegend unterschiedliche Zuverlaessigkeits- oder Latenzanforderungen haben. Ueberall sonst waehlen Teams einfachere Architekturen und reservieren Microservices fuer die spezifischen Faelle, die sie erfordern.

Wann der Monolith gewinnt

Ein Monolith ist die richtige Voreinstellung fuer die meisten Projekte. Dies ist unter erfahrenen Architekten keine kontroverse Aussage, aber sie widerspricht der Botschaft, die viele Entwickler waehrend des Microservices-Hype-Zyklus aufgenommen haben. Der Monolith gewinnt in mehr Szenarien, als er verliert, und der Schluessel ist zu wissen, welche Szenarien das sind.

Die Teamgroesse ist der staerkste einzelne Praediktor fuer architektonischen Erfolg. Wenn Ihr Team weniger als zehn Entwickler hat, ist ein Monolith mit ziemlicher Sicherheit die richtige Wahl. Bei einem kleinen Team verbraucht der Koordinationsaufwand von Microservices - das Abstimmen von Dienstgrenzen, das Verwalten von Vertraegen zwischen Diensten, das Betreiben mehrerer Deployment-Pipelines - einen erheblichen Teil Ihrer verfuegbaren Engineering-Kapazitaet. Jede Dienstgrenze, die Sie schaffen, ist ein Vertrag, den Sie pflegen muessen, und Vertragspflege ist Arbeit, die keine Funktionen ausliefert.

Die Start-up-Phase ist ein weiteres klares Signal. Wenn Ihr Produkt weniger als zwei Jahre alt ist oder sich Ihr Geschaeftsmodell noch entwickelt, bewahrt ein Monolith Ihre Faehigkeit, schnell die Richtung zu aendern. Microservices legen Annahmen ueber Domaenengrenzen fest, die Sie im ersten Jahr mit ziemlicher Sicherheit falsch treffen werden. Ein Monolith laesst Sie frei refaktorisieren. Wenn Ihre gesamte Anwendung eine Codebasis ist, ist das Verschieben einer Funktion von einem Modul in ein anderes ein Refactoring-Vorgang. Wenn Ihre Anwendung aus zehn Diensten besteht, erfordert das Verschieben einer Funktion das Aendern von Dienstschnittstellen, das Aktualisieren von Konsumenten, das Koordinieren von Deployments und das Migrieren von Daten.

# What a simple monolith deployment looks like in 2026
# A single Dockerfile, a single service, zero orchestration

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/server.js"]

# One docker-compose.yml for the entire stack
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://db:5432/app
  db:
    image: postgres:17
    volumes:
      - pgdata:/var/lib/postgresql/data

Die operationelle Einfachheit dieses Setups kann kaum genug betont werden. Ein Dienst zu ueberwachen, ein Satz von Logs zu pruefen, ein Deployment zurueckzusetzen. Ein Junior-Entwickler kann die gesamte Deployment-Pipeline an einem Nachmittag verstehen. Wenn etwas kaputt geht, gibt es genau einen Ort, an dem man nach der Ursache suchen muss. Diese Einfachheit ist kein Luxus - sie ist ein strategischer Vorteil, der sich mit der Zeit summiert.

Die Domaenenkomplexitaet ist ein weiterer Faktor, der in Richtung Monolith drueckt. Paradoxerweise gilt: Je komplexer Ihre Domaene ist, desto gefaehrlicher ist eine vorzeitige Dienstzerlegung. Wenn Sie eine komplexe Domaene in Dienste aufteilen, bevor Sie ihre natuerlichen Grenzen verstehen, werden Sie Dienste schaffen, die auf die falsche Weise stark gekoppelt sind - Dienste, die nicht unabhaengig bereitgestellt werden koennen, weil die Aenderung eines Dienstes die Aenderung eines anderen erfordert, Dienste, die sich Datenbanken teilen, weil sich die Daten nicht sauber teilen lassen, Dienste, die im Gleichschritt bereitgestellt werden muessen, weil sich ihre Vertraege staendig aendern.

Der modulare Monolith: Die Architektur, die die meisten Teams nie in Betracht ziehen

Die krasse Wahl zwischen Monolith und Microservices ist eine falsche Dichotomie. Der modulare Monolith nimmt die Mitte ein und ist fuer mehr Teams die richtige Antwort als jedes der Extreme. Ein modularer Monolith ist eine einzelne Bereitstellungseinheit mit klar definierten internen Modulen, die denselben Grenzregeln folgen wie Microservices, aber ohne das Netzwerk.

Der Hauptunterschied zwischen einem modularen Monolithen und einem typischen Monolithen ist die Disziplin. In einem typischen Monolithen sind Module nicht erzwungen - jeder Code kann jeden anderen Code importieren, und mit der Zeit zerfallen die Grenzen zu einem Schlamassel. In einem modularen Monolithen haben Module explizite oeffentliche APIs und private Implementierungen. Modul A kann nur ueber B's definierte Schnittstelle mit Modul B interagieren. Der direkte Datenbankzugriff ueber Modulgrenzen hinweg ist verboten. Dieselben Regeln, die die Microservice-Kommunikation regeln, gelten auch hier, aber die Kommunikation erfolgt ueber Funktionsaufrufe anstelle von HTTP-Anfragen.

Dieser Ansatz gibt Ihnen die meisten Vorteile von Microservices - erzwungene Grenzen, unabhaengige Entwicklung innerhalb der Module, klare Vertraege - ohne die Betriebskosten. Sie haben eine Deployment-Pipeline, eine zu ueberwachende Anwendung und eine zu navigierende Codebasis. Aber Sie haben auch Modulgrenzen, die das Schlamassel-Problem verhindern und eine zukuenftige Extraktion zu Microservices unkompliziert machen.

// A modular monolith boundary in TypeScript
// Each module exposes only its public API

// modules/orders/public-api.ts
export {
  createOrder,
  getOrderById,
  getOrdersByUser,
  OrderService,
} from "./order-service";

// modules/orders/internal/  ← everything here is private
//   order-repository.ts
//   order-validator.ts
//   order-pricing.ts

// modules/payments/public-api.ts
export {
  processPayment,
  getPaymentStatus,
  refundPayment,
} from "./payment-service";

// Cross-module dependency is explicit and auditable
// payments/payment-service.ts imports from orders/public-api
import { getOrderById } from "../../orders/public-api";

Der modulare Monolith ist auch die beste Absicherung gegen eine ungewisse Zukunft. Wenn Sie einen modularen Monolithen bauen und spaeter feststellen, dass ein Modul zu einem unabhaengigen Dienst werden muss, ist die Extraktion mechanisch: Sie kopieren den Code des Moduls in einen neuen Dienst, machen seine oeffentliche API ueber HTTP oder eine Message Queue zugaenglich und verkabeln den Aufrufer. Die Modulgrenzen existieren bereits. Die Schnittstellen sind bereits definiert. Die harte Arbeit - das Verstehen der Domaenengrenzen - ist bereits erledigt.

Wenn Sie einen traditionellen Monolithen ohne Modulgrenzen bauen und spaeter Dienste extrahieren wollen, stehen Sie vor einem viel schwierigeren Problem. Sie muessen zunaechst herausfinden, wo die Grenzen sein sollten, dann den Code refaktorisieren, um sie zu respektieren, und erst dann extrahieren. Deshalb scheitern die meisten Monolith-zu-Microservices-Migrationen - Teams unterschatzen die Arbeit der Grenzfindung und landen bei Microservices, die auf eine Weise gekoppelt sind, die den Zweck zunichte macht.

• Modularer Monolith: einzelne bereitstellbare Einheit, Netzwerkaufrufe durch Funktionsaufrufe ersetzt, erzwungene Modulgrenzen, einfacher Extraktionspfad.
• Traditioneller Monolith: einzelne bereitstellbare Einheit, keine erzwungenen Grenzen, maximale Freiheit in fruehen Phasen, schmerzhafter Extraktionspfad.
• Microservices: viele bereitstellbare Einheiten, Netzwerkaufrufe zur Kommunikation, erzwungene Dienstgrenzen, hohe Betriebskosten.
• Der modulare Monolith ist in der Regel der beste Ausgangspunkt, weil er Optionen offen haelt, ohne sich auf die Komplexitaet verteilter Systeme festzulegen.

Wann Microservices tatsaechlich Sinn machen

Microservices sind nicht falsch. Sie sind fuer die meisten Teams falsch, aber es gibt Szenarien, in denen die Kosten durch den Nutzen gerechtfertigt sind. Der Schluessel ist, ehrlich zu sein, ob Ihr Szenario tatsaechlich passt.

Unabhaengige Skalierung ist der am besten zu verteidigende Grund fuer Microservices. Wenn verschiedene Teile Ihres Systems dramatisch unterschiedliche Skalierungsprofile haben - Ihr API-Gateway muss 100.000 Anfragen pro Sekunde verarbeiten, waehrend Ihr Reporting-Dienst 100 Anfragen pro Stunde verarbeitet - dann verschwendet die Unterbringung in derselben Bereitstellungseinheit Ressourcen. Die Hardware des Reporting-Dienstes sitzt ungenutzt herum, und die automatische Skalierung des API-Gateways wird durch die Kaltstartzeit des Reporting-Dienstes eingeschraenkt. Separate Dienste koennen unabhaengig skaliert werden, und die Kosteneinsparungen durch effiziente Ressourcennutzung koennen den operativen Overhead ausgleichen.

Teamautonomie ist der zweite legitime Grund. Wenn mehrere Teams am selben System arbeiten und jedes Team unabhaengig in seinem eigenen Rhythmus bereitstellen muss, beseitigen Microservices den Koordinationsengpass. Team A kann seinen Dienst dreimal taeglich bereitstellen, ohne auf die Freigabe von Team B warten zu muessen. Aber beachten Sie die Schwelle: Dieses Argument gilt nur, wenn Sie mehrere Teams haben. Wenn Ihre Organisation insgesamt zehn Entwickler hat, haben Sie kein Koordinationsproblem, das Microservices loesen. Sie haben ein Kommunikationsproblem, das ein gemeinsamer Slack-Channel loesen kann.

Unterschiedliche Zuverlaessigkeits- oder Latenzanforderungen rechtfertigen ebenfalls Microservices. Wenn Ihr Zahlungsabwicklungsdienst eine Verfuegbarkeit von 99,999 % benoetigt, waehrend Ihr Analysedienst gelegentliche Ausfallzeiten tolerieren kann, stellt die Trennung sicher, dass ein Fehler in der Analyseberichterstattung Kunden nicht am Bezahlen hindert. Wenn ein Teil Ihres Systems extrem niedrige Latenz erfordert und ein anderer hoehere Latenz tolerieren kann, koennen Sie durch die Trennung jeden Teil unabhaengig optimieren.

Technologievielfalt ist das schwachste Argument fuer Microservices. Ja, Microservices ermoeglichen die Verwendung verschiedener Sprachen und Datenbanken fuer verschiedene Dienste. Aber in der Praxis konvergieren die meisten Organisationen ohnehin auf eine kleine Anzahl von Technologien, und die Betriebskosten fuer die Wartung mehrerer Laufzeitumgebungen uebersteigen in der Regel den Nutzen. Wenn Ihr gesamtes Team TypeScript und PostgreSQL beherrscht, ist der Bau eines Dienstes in Rust und eines anderen in Go, nur um eine andere Technologie zu verwenden, ein Luxus, den sich die meisten Organisationen nicht leisten koennen.

Das Muster: Mit Monolith starten, Dienste extrahieren

Das zuverlaessigste Muster fuer den Bau von Softwaresystemen im Jahr 2026 ist auch das einfachste: Starten Sie mit einem modularen Monolithen und extrahieren Sie dann Dienste, wenn Sie Beweise dafuer haben, dass Sie sie brauchen. Dies wird manchmal als Monolith-zuerst- oder Extrahiere-Microservices-Muster bezeichnet und ist zur Standardempfehlung von Organisationen geworden, die den Microservices-Hype-Zyklus durchgemacht und ueberlebt haben.

Das Muster funktioniert in vier Phasen. Phase eins ist der modulare Monolith. Sie bauen Ihre gesamte Anwendung als eine einzige bereitstellbare Einheit mit strengen Modulgrenzen. Jedes Modul besitzt seine Daten, macht eine oeffentliche API zugaenglich und haelt seine Implementierung privat. Sie verwenden dieselbe Disziplin, die Sie auch fuer Microservices verwenden wuerden - klare Vertraege, getrennte Datenverantwortung, explizite Abhaengigkeiten -, aber alles laeuft in einem einzigen Prozess.

Phase zwei ist die Messung. Sie ueberwachen, welche Module sich am haeufigsten aendern, welche Teams an welchen Modulen arbeiten und welche Module unterschiedliche Skalierungs- oder Zuverlaessigkeitsanforderungen haben. Sie extrahieren Dienste nicht aufgrund von Intuition oder Spekulation. Sie extrahieren sie auf der Grundlage von Daten - echten Beweisen dafuer, dass der Monolith einen Engpass schafft, den eine Dienstgrenze aufloesen wuerde.

Phase drei ist die Extraktion. Sie nehmen ein Modul, das bewiesen hat, dass es ein Dienst sein muss - weil seine Aenderungshaeufigkeit zu vielen Deployments des Monolithen fuehrt oder weil seine Skalierungsanforderungen sich vom Rest des Systems unterscheiden - und extrahieren es. Da das Modul bereits saubere Grenzen hat, ist die Extraktion mechanisch. Sie erstellen einen neuen Dienst mit eigener Deployment-Pipeline, machen die oeffentliche API des Moduls ueber HTTP oder eine Message Queue zugaenglich und aktualisieren den Monolithen so, dass er den neuen Dienst anstelle des Moduls direkt aufruft.

// Step 1: Define the extraction candidate as a module
// monolith/src/modules/reports/public-api.ts
export async function generateReport(
  reportId: string
): Promise<ReportResult> {
  // Implementation detail: queries a separate read-replica,
  // takes 30 seconds, should not block the main application
}

// Step 2: When evidence shows this needs to be a service:
// 1. Create a new service from the module code
// 2. Expose the same API over HTTP
// 3. Replace the direct call with a service client

// monolith/src/clients/reporting-service.ts
const client = new ServiceClient({
  name: "reporting",
  baseUrl: process.env.REPORTING_SERVICE_URL,
  timeout: 60000, // This service is slow
});

export async function generateReport(reportId: string) {
  return client.post("/reports", { reportId });
}

// The monolith does not need to redeploy — the client handles
// retries, timeouts, and circuit breaking internally.

Phase vier ist die Wiederholung. Wenn das System waechst, wiederholen Sie den Zyklus - messen, extrahieren, erneut messen. Einige extrahierte Dienste muessen moeglicherweise weiter in kleinere Dienste zerlegt werden. Einige muessen moeglicherweise wieder in den Monolithen eingegliedert werden, wenn die Extraktion keinen Mehrwert gebracht hat. Der Schluessel ist, dass jede Extraktion durch Beweise gesteuert wird, nicht durch architektonische Dogmen.

Dieses Muster hat einen entscheidenden Vorteil gegenueber dem Microservices-zuerst-Ansatz: Es verschiebt irreversible Entscheidungen. Jede von Ihnen geschaffene Dienstgrenze ist eine irreversible Verpflichtung zur Komplexitaet verteilter Systeme. Sobald ein Dienst existiert, koennen Sie seine Grenzen nicht einfach aendern, ohne Clients zu beeintraechtigen. Indem Sie mit einem Monolithen starten und nur bei Bedarf extrahieren, stellen Sie sicher, dass jede Dienstgrenze durch tatsaechliche Anforderungen gerechtfertigt ist und nicht durch Spekulationen ueber zukuenftige Beduerfnisse.

Wie man waehlt: Ein Entscheidungsrahmen

Wenn Sie ein neues System entwerfen oder Ihre aktuelle Architektur bewerten, gehen Sie diese Fragen der Reihe nach durch. Die Antworten werden Sie zur richtigen Architektur fuehren, ohne dass Sie die Zukunft vorhersagen muessen.

Erste Frage: Wie viele Entwickler arbeiten an diesem System? Wenn die Antwort weniger als zehn ist, starten Sie mit einem Monolithen - vorzugsweise einem modularen. Sie haben kein Koordinationsproblem, das Microservices loesen, und Sie koennen sich den operativen Overhead nicht leisten. Wenn die Antwort mehr als zehn ist, haengt die Antwort davon ab, wie sie organisiert sind. Wenn sie als ein Team arbeiten, funktioniert ein Monolith immer noch. Wenn sie in mehrere autonome Teams organisiert sind, koennen Microservices eine Ueberlegung wert sein.

Zweite Frage: Hat Ihr System Komponenten mit grundlegend unterschiedlichen Skalierungsprofilen? Wenn jeder Teil Ihres Systems mit ungefaehr der gleichen Rate skaliert werden muss, bringt eine Trennung keinen Vorteil. Wenn eine Komponente zehntausend Anfragen pro Sekunde verarbeiten muss, waehrend eine andere zehn verarbeitet, trennen Sie sie - aber beginnen Sie damit, nur die hochskalierende Komponente in einen eigenen Dienst auszugliedern, nicht das gesamte System.

Dritte Frage: Koennen Sie alle Teile Ihres Systems nach demselben Zeitplan bereitstellen? Wenn ja, vereinfacht ein Monolith Ihre Deployment-Pipeline und reduziert den Koordinationsaufwand. Wenn nein - weil verschiedene Teile des Systems unterschiedliche Release-Zyklen, regulatorische Anforderungen oder Risikoprofile haben - ermoeglichen Microservices es jedem Teil, seinen eigenen Deployment-Rhythmus zu haben.

Vierte Frage: Was wuerde passieren, wenn jeder Teil Ihres Systems gleichzeitig ausfiele? Wenn die Antwort ist, dass Ihr Geschaeft vollstaendig zum Erliegen kommt, gewinnen Sie durch Microservices keine Widerstandsfaehigkeit - Sie zahlen nur die Kosten. Echte Widerstandsfaehigkeit erfordert nicht nur separate Dienste, sondern separate Infrastruktur, separate Datenspeicher und eine geordnete Degradierung zwischen den Diensten. Die meisten Teams bauen das nicht. Sie bauen Dienste, die in der Bereitstellung eng gekoppelt und in der Theorie lose gekoppelt sind, was das Schlimmste aus beiden Welten ist.

Die beste Architektur ist die, die Ihr Team sicher bereitstellen, schnell debuggen und ohne Angst aendern kann. Was auch immer das fuer Ihre spezifische Organisation bedeutet - Monolith, modularer Monolith oder Microservices - ist die richtige Antwort. Alles andere ist architektonische Mode, die als Ingenieursprinzip verkleidet ist.

Fuenfte Frage: Wie sicher sind Sie sich ueber Ihre Domaenengrenzen? Wenn Sie in einer gut verstandenen Domaene mit etablierten Mustern bauen - E-Commerce, Content-Management, Abrechnung - sind Ihre Domaenengrenzen relativ stabil, und Microservices sind weniger riskant. Wenn Sie in einer neuartigen Domaene bauen, in der sich die Grenzen noch herauskristallisieren, bewahrt ein Monolith Ihre Faehigkeit zu refaktorisieren, wenn sich Ihr Verstaendnis weiterentwickelt. Vorzeitige Dienstgrenzen werden zu Einschraenkungen, die genau den Lernprozess verlangsamen, den Sie durchfuehren muessen.

Die ehrliche Antwort fuer die meisten Teams im Jahr 2026 ist ein modularer Monolith. Er gibt Ihnen die Disziplin der Microservices ohne die Betriebskosten. Er bewahrt die Option, spaeter Dienste zu extrahieren, ohne Sie heute auf die Komplexitaet verteilter Systeme festzulegen. Er ist von einem einzelnen Entwickler bereitstellbar, mit einem einzigen Log-Stream debugbar und mit einem einzigen Pull Request aenderbar. Und wenn Ihr System so weit waechst, dass ein Monolith nicht mehr funktioniert, werden die von Ihnen gebauten modularen Grenzen den Uebergang zu Microservices reibungsloser gestalten, als Sie erwarten.

Das Architekturpendel hat zurueck zur Einfachheit geschwungen. Das ist kein Rueckschritt. Es ist die Branche, die aus Erfahrung lernt. Die Teams, die den Hype ignoriert oder sich schnell davon erholt haben, sind diejenigen, die Funktionen ausliefern, nicht Dienste migrieren. Waehlen Sie die Architektur, die es Ihnen ermoeglicht, auszuliefern, und aendern Sie sie nur, wenn Ihr System Ihnen sagt, dass sie geaendert werden muss.