Microservices vs Monolith: Wann welche Architektur im Interview wählen

„Design a system for…” steht auf dem Whiteboard. Du hast 45 Minuten. Und die erste Entscheidung, die du treffen musst, ist gleichzeitig die wichtigste: Monolith oder Microservices?

Die meisten Kandidaten greifen reflexartig zu Microservices. Sie zeichnen sechs Services, eine Message Queue, ein API Gateway und verlieren die Hälfte ihrer Zeit damit, die Kommunikation zwischen Komponenten zu erklären, die in einem einzigen Service besser aufgehoben wären. Der Interviewer macht sich eine Notiz: „Over-Engineering. Keine Begründung für die Architekturwahl.”

Das Problem ist nicht mangelndes Wissen über Microservices. Das Problem ist, dass die meisten Kandidaten nie gelernt haben, wann welche Architektur die richtige Antwort ist. In diesem Guide lernst du die Entscheidungskriterien, die Interviewer sehen wollen, wie du Trade-offs überzeugend formulierst und welche Fehler dich die Runde kosten.

Warum diese Frage im Interview so oft vorkommt🔗

Was Interviewer testen🔗

Die Frage „Monolith oder Microservices?” ist kein Quiz. Sie ist ein Proxy für drei Fähigkeiten, die im Arbeitsalltag zählen: Kontextbewusstsein, Trade-off-Denken und die Fähigkeit, Entscheidungen unter Unsicherheit zu treffen.

Interviewer wollen sehen, dass du nicht einfach eine Architektur aus einem YouTube-Tutorial kopierst. Sie wollen verstehen, wie du den Kontext analysierst (Teamgröße, Skalierungsanforderungen, Domänenkomplexität) und daraus eine begründete Entscheidung ableitest. Das ist die gleiche Fähigkeit, die du brauchst, wenn du in der Praxis eine Architekturentscheidung für ein reales Projekt triffst.

Bei deutschen Tech-Unternehmen kommt eine Erwartung hinzu: Pragmatismus. Wer ein System für 1.000 Nutzer mit einer Architektur für 100 Millionen Nutzer entwirft, zeigt dem Interviewer nicht technische Tiefe, sondern mangelndes Augenmaß. Deutsche Interviewer schätzen Kandidaten, die das einfachste Design wählen, das die Anforderungen erfüllt, und erst dann skalieren, wenn der Kontext es verlangt.

Der Reflex zum Microservice🔗

Microservices haben in den letzten Jahren enormen Hype erfahren. Jeder Konferenzvortrag, jeder Blog-Post, jede Architektur-Dokumentation großer Unternehmen scheint Microservices als Standard darzustellen. Das hat zu einem Reflex geführt: Viele Kandidaten wählen Microservices als Default, ohne darüber nachzudenken, ob sie im gegebenen Kontext sinnvoll sind.

Dieser Reflex ist einer der häufigsten Gründe für negative Bewertungen in System Design Interviews. Nicht weil Microservices schlecht wären, sondern weil eine unbegründete Entscheidung dem Interviewer zeigt, dass der Kandidat den Hype nicht von der Realität unterscheiden kann. Die Fähigkeit, bewusst „Nein, hier reicht ein Monolith” zu sagen und das zu begründen, ist ein stärkeres Signal als jede Microservice-Architektur.

Monolith: Stärken, Schwächen und wann er die richtige Antwort ist🔗

Was ein Monolith gut kann🔗

Ein Monolith ist eine einzige, zusammenhängende Anwendung, die als ein Artefakt deployed wird. Alle Komponenten teilen sich denselben Prozess, dieselbe Datenbank und denselben Deployment-Zyklus.

Das klingt altmodisch, bringt aber konkrete Vorteile. Debugging ist einfacher, weil du einen Stack-Trace von der UI bis zur Datenbank verfolgen kannst, ohne über Servicegrenzen hinweg Logs korrelieren zu müssen. Datenkonsistenz ist trivial, weil alle Operationen in derselben Datenbank laufen und du echte Transaktionen nutzen kannst. Deployment ist ein einzelner Schritt, nicht eine Orchestrierung von zwanzig Services mit unterschiedlichen Versionsständen. Und für kleine Teams (unter zehn Developer) eliminiert ein Monolith die Koordinations-Overhead, die Microservices erzeugen.

Shopify verarbeitet Milliarden von Dollar an Transaktionen auf einem Monolithen. Stack Overflow bedient Millionen von Anfragen pro Tag mit einer monolithischen Anwendung. Diese Beispiele zeigen: Die Architekturentscheidung hängt nicht davon ab, wie groß das System ist, sondern davon, ob die Komplexität des Systems die Kosten einer verteilten Architektur rechtfertigt.

Wann du im Interview den Monolith wählen solltest🔗

Drei Kriterien sprechen im Interview für den Monolith:

Kleines Team: Wenn der Interviewer ein Szenario beschreibt, in dem ein Team von fünf bis zehn Developern das System baut und betreibt, ist ein Monolith fast immer die bessere Wahl. Die Koordinationskosten von Microservices übersteigen bei dieser Teamgröße den Nutzen.

Frühe Produktphase: Wenn das System neu ist und die Domänengrenzen noch nicht klar sind, ist ein Monolith der sicherere Start. Du kannst die Domäne erkunden, Module identifizieren und später gezielt Services extrahieren, wenn die Grenzen sich stabilisiert haben. Microservices von Anfang an zu schneiden, bevor du die Domäne verstehst, führt zu falschen Service-Grenzen, die später teuer zu korrigieren sind.

Geringe Skalierungsunterschiede: Wenn alle Teile des Systems ähnliche Last-Muster haben und keine einzelne Komponente unabhängig skaliert werden muss, gibt es keinen technischen Grund für Microservices.

Formuliere es im Interview so: „Angesichts der beschriebenen Teamgröße und der frühen Produktphase würde ich mit einem gut strukturierten Monolithen starten. Das gibt uns schnellere Iterationszyklen und wir vermeiden die operative Komplexität verteilter Systeme, solange sie keinen klaren Nutzen bringt.”

Microservices: Stärken, Schwächen und wann sie die richtige Antwort sind🔗

Was Microservices ermöglichen🔗

Microservices sind unabhängig deploybare Services, die jeweils eine abgegrenzte Geschäftsdomäne abdecken. Jeder Service hat seine eigene Datenbank, seinen eigenen Deployment-Zyklus und kann von einem eigenen Team entwickelt werden.

Die Stärken liegen dort, wo Monolithe an Grenzen stoßen. Unabhängiges Deployment bedeutet, dass ein Team seinen Service aktualisieren kann, ohne auf andere Teams warten zu müssen. Unabhängige Skalierung ermöglicht es, den Suchdienst auf 50 Instanzen hochzufahren, während der Nutzerverwaltungs-Service auf drei Instanzen läuft. Technologiefreiheit erlaubt es Teams, die beste Sprache oder Datenbank für ihren Use Case zu wählen. Und Fehlerisolation verhindert, dass ein Bug in einem Service das gesamte System herunterzieht.

Die Kosten, die Kandidaten unterschätzen🔗

Hier zeigt sich, ob ein Kandidat theoretisches Wissen hat oder praktische Erfahrung. Die Kosten von Microservices sind real und erheblich:

Netzwerkkommunikation: Jeder Aufruf zwischen Services geht über das Netzwerk. Das bedeutet Latenz, mögliche Timeouts und die Notwendigkeit, mit Netzwerkfehlern umzugehen. Ein Funktionsaufruf innerhalb eines Monolithen dauert Nanosekunden. Ein HTTP-Call zwischen Services dauert Millisekunden, und das summiert sich.

Verteilte Transaktionen: Wenn eine Geschäftsoperation mehrere Services betrifft (Bestellung erstellen + Lagerbestand reduzieren + Zahlung auslösen), brauchst du Saga-Patterns oder Two-Phase-Commits. Beides ist komplex und fehleranfällig. Im Monolith ist das eine Datenbanktransaktion.

Observability: Wenn ein Request durch fünf Services läuft und fehlschlägt, brauchst du Distributed Tracing, zentralisiertes Logging und Service Meshes, um das Problem zu finden. Das ist eine eigene Infrastruktur-Disziplin.

Operative Komplexität: Zwanzig Services bedeuten zwanzig CI/CD-Pipelines, zwanzig Monitoring-Dashboards, zwanzig Sets von Health Checks. Dafür brauchst du ein Platform-Team oder zumindest ein sehr reifes DevOps-Setup.

Wenn du diese Kosten im Interview benennst, zeigst du dem Interviewer, dass du nicht nur die Architektur-Folien kennst, sondern verstehst, was es bedeutet, ein verteiltes System in Produktion zu betreiben.

Wann du im Interview Microservices wählen solltest🔗

Microservices sind die richtige Wahl, wenn der Kontext ihre Kosten rechtfertigt:

Mehrere unabhängige Teams: Wenn der Interviewer ein Szenario mit 50+ Developern beschreibt, die in mehreren Teams arbeiten, ermöglichen Microservices autonomes Arbeiten ohne Deployment-Konflikte.

Unterschiedliche Skalierungsanforderungen: Wenn der Video-Transcoding-Service 100x mehr Rechenleistung braucht als der User-Profile-Service, ist unabhängige Skalierung ein starkes Argument.

Klare Domänengrenzen: Wenn das System eine gut verstandene Domäne hat, in der die Grenzen zwischen Geschäftsfähigkeiten offensichtlich sind (Bestellungen, Zahlungen, Versand, Nutzerverwaltung), können Services entlang dieser Grenzen geschnitten werden.

Entscheidungsframework für das Interview🔗

Die vier Fragen, die deine Entscheidung leiten🔗

Statt über abstrakte Vor- und Nachteile zu referieren, stelle dir im Interview vier konkrete Fragen:

1. Wie groß ist das Team? Unter 10 Developer → Monolith. Über 30 → Microservices ernsthaft erwägen. Dazwischen → kontextabhängig.
2. Gibt es unterschiedliche Skalierungsanforderungen? Wenn ja → Microservices für die Komponenten, die unabhängig skalieren müssen.
3. Wie klar sind die Domänengrenzen? Neue Domäne mit unsicheren Grenzen → Monolith-first. Etablierte Domäne mit klaren Bounded Contexts → Microservices möglich.
4. Wie reif ist die operative Infrastruktur? Kein Kubernetes, kein Observability-Stack → Microservices werden zur operativen Last.

Diese vier Fragen kannst du dem Interviewer laut stellen. Das zeigt strukturiertes Denken und gibt dir gleichzeitig die Informationen, die du für eine begründete Entscheidung brauchst.

[1] Bei personenbezogenen Daten ist die Einhaltung der DSGVO in einer zentralen Datenhaltung einfacher umzusetzen als über verteilte Services hinweg, wo das Recht auf Löschung koordiniert werden muss.

Wie du Trade-offs im Interview formulierst🔗

Die Formulierung macht den Unterschied. Vergleiche diese zwei Antworten:

Schwach: „Ich wähle Microservices, weil sie besser skalieren.”

Stark: „Für dieses Szenario würde ich mit einem modularen Monolithen starten. Das Team hat sieben Developer und das Produkt ist in einer frühen Phase, in der sich die Domänengrenzen noch verschieben können. Die Module strukturiere ich entlang der Geschäftsdomänen, sodass wir später einzelne Module als Services extrahieren können, wenn das Team wächst oder bestimmte Komponenten unabhängig skaliert werden müssen. Der Trade-off ist, dass wir kurzfristig keine unabhängigen Deployments haben, aber die operative Einfachheit überwiegt in dieser Phase.”

Die starke Antwort nennt den Kontext, die Entscheidung, die Begründung und den Trade-off. Das ist die Struktur, die Interviewer sehen wollen. Mehr dazu, wie du System Design Interviews in Deutschland generell angehst, findest du im System Design Interview Guide.

Fehler, die du vermeiden solltest🔗

Microservices ohne Begründung wählen🔗

Der häufigste Fehler. Kandidaten zeichnen Microservices, weil „das ist halt der moderne Ansatz”. Ohne Kontext ist das keine Architekturentscheidung, sondern ein Reflex. Wenn dich der Interviewer fragt „Warum nicht ein Monolith?” und du keine überzeugende Antwort hast, hast du gerade gezeigt, dass du die Entscheidung nicht bewusst getroffen hast.

Den Monolith als „veraltet” abtun🔗

Monolithe sind nicht veraltet. Sie sind eine bewusste Architekturentscheidung. Viele erfolgreiche Systeme laufen als Monolithe, und Unternehmen wie Shopify oder Basecamp haben öffentlich argumentiert, warum sie bewusst beim Monolithen bleiben. Wer den Monolithen als minderwertig darstellt, signalisiert dem Interviewer eine eindimensionale Sichtweise.

Hybride Ansätze ignorieren🔗

Monolith und Microservices sind nicht die einzigen Optionen. Der modulare Monolith ist ein Architekturmuster, das die Vorteile beider Welten kombiniert: interne Modularität mit klaren Schnittstellen, aber ohne die operative Komplexität verteilter Systeme. Auch ein „Monolith + ein extrahierter Service” für eine spezifische Skalierungsanforderung ist eine valide Antwort.

Im technischen Interview Playbook zeigen wir, wie du generell mit offenen technischen Fragen umgehst und den Interviewer durch deinen Denkprozess führst.

DSGVO und Datenhaltung vergessen🔗

Bei deutschen Unternehmen ist die DSGVO keine Randnotiz. Wenn du Microservices wählst und personenbezogene Daten über mehrere Services verteilst, musst du erklären, wie du das Recht auf Löschung umsetzt. In welchem Service liegen die Daten? Wie stellst du sicher, dass eine Löschanfrage alle betroffenen Services erreicht? Wo werden die Daten physisch gespeichert?

Wer diese Fragen proaktiv anspricht, hebt sich positiv ab. Die meisten internationalen Vorbereitungsressourcen behandeln DSGVO gar nicht, was bei Interviews in Deutschland eine Lücke hinterlässt.

Deutsche Tech-Unternehmen: Was sie wirklich einsetzen🔗

Konzerne und Mittelstand🔗

Viele deutsche Konzerne haben ihre Wurzeln in monolithischen Architekturen. SAP ist das bekannteste Beispiel: jahrzehntelang gebaut auf einer monolithischen Kernarchitektur, die sukzessive modularisiert wurde. Ähnliche Muster finden sich bei Unternehmen wie Siemens und Bosch im IoT-Bereich.

Der deutsche Mittelstand, der einen erheblichen Teil der Tech-Arbeitgeber stellt, setzt ebenfalls überwiegend auf monolithische oder modular-monolithische Architekturen. Das liegt nicht an technischem Rückstand, sondern an einer pragmatischen Einschätzung: Die Teams sind klein genug, dass ein Monolith effizienter ist, und die Skalierungsanforderungen rechtfertigen keine verteilte Architektur.

Wenn du dich bei einem solchen Unternehmen bewirbst und im Interview reflexartig Microservices vorschlägst, wirkt das, als würdest du ihre bestehende Architektur implizit kritisieren. Das kommt nicht gut an.

Startups und Scale-ups🔗

Berliner und Münchner Startups beginnen typischerweise mit einem Monolithen und migrieren zu Microservices, wenn das Team über 30-40 Developer wächst. Zalando hat diesen Weg öffentlich dokumentiert: vom Monolithen über einen „Strangler Fig”-Ansatz zu Microservices.

Delivery Hero, N26 und Trade Republic setzen auf Microservice-Architekturen, aber das kam nicht von Anfang an. Der Übergang geschah über Jahre, begleitet von Platform-Teams, die die operative Infrastruktur aufgebaut haben.

Im Interview bei einem Startup ist die stärkste Antwort oft: „Für den aktuellen Stand des Produkts würde ich mit einem Monolithen starten und Module so schneiden, dass eine spätere Extraktion möglich ist.” Das zeigt Erfahrung mit dem evolutionären Ansatz, den die meisten erfolgreichen Startups tatsächlich durchlaufen.

So bereitest du dich gezielt vor🔗

Übungsaufgaben mit Architekturentscheidung🔗

Nimm dir drei System-Design-Aufgaben vor und löse jede davon zweimal: einmal als Monolith, einmal als Microservices. Vergleiche die Ergebnisse. Wo war der Monolith stärker? Wo die Microservices? Das trainiert dein Urteilsvermögen besser als jede theoretische Abhandlung.

Gute Übungsszenarien:

• E-Commerce-Plattform für 1.000 Bestellungen pro Tag, Team von 8: Monolith ist hier fast sicher die richtige Wahl. Begründe warum.
• Video-Streaming-Dienst mit 1 Million Nutzern, Team von 40: Hier gibt es gute Argumente für Microservices. Der Transcoding-Service hat völlig andere Skalierungsanforderungen als der User-Profile-Service.
• Internes Tool für 500 Mitarbeiter eines Mittelständlers: Monolith. Die Anforderungen an Skalierung sind gering, das Team ist klein, und die operative Einfachheit ist ein klarer Vorteil.

Sprich bei jeder Übung laut, als ob ein Interviewer zuhört. Erkläre deine Entscheidung, benenne die Trade-offs und beschreibe, wann du die andere Architektur gewählt hättest.

Mock-Interviews mit echtem Feedback🔗

Alleine üben ist der erste Schritt. Aber die Entscheidung Monolith vs. Microservices lebt davon, wie überzeugend du sie kommunizierst. Du brauchst jemanden, der dir sagt, ob deine Begründung schlüssig klingt, ob du den richtigen Detailgrad triffst und ob du Trade-offs vergisst, die ein Interviewer erwartet hätte.

CodingCareers Mock System Design Interviews simulieren das Format deutscher Tech-Unternehmen. Ein erfahrener Developer spielt den Interviewer, stellt Rückfragen zu deinen Architekturentscheidungen und gibt dir konkretes Feedback zu Struktur, Kommunikation und technischer Tiefe. Anders als generische Interview-Plattformen, die auf FAANG-Scale-Probleme trainieren, fokussiert CodingCareer auf die pragmatischen Architekturentscheidungen, die bei deutschen Unternehmen tatsächlich gefragt werden.

Das Ergebnis ist nicht nur ein besseres Interview, sondern ein besseres Verständnis dafür, wie du Architekturentscheidungen in deiner täglichen Arbeit triffst und kommunizierst.

Buche dein kostenloses 15-Minuten-Diagnosegespräch und finde heraus, wo du in deiner System-Design-Vorbereitung stehst.