System Design Interview: Die 10 wichtigsten Patterns

Du sitzt im System Design Interview, der Interviewer sagt „Entwirf ein System, das 10 Millionen Nutzer bedient”, und du fängst an, Boxen zu zeichnen. Irgendwann kommt der Punkt, an dem du entscheiden musst: Wie verteile ich die Last? Wo cache ich? Wie kommunizieren die Services untereinander? Wenn du in diesem Moment zum ersten Mal über diese Fragen nachdenkst, ist es zu spät.

System Design Interviews testen nicht, ob du eine perfekte Architektur aus dem Ärmel schütteln kannst. Sie testen, ob du ein Repertoire an bewährten Architektur-Patterns hast und weißt, wann du welches einsetzt. Die gute Nachricht: Die allermeisten Aufgaben bei deutschen Tech-Unternehmen lassen sich mit denselben zehn Patterns lösen.

Dieser Guide erklärt jedes Pattern, zeigt dir, in welchem Interviewkontext es auftaucht, und gibt dir die Argumentation, die Interviewer hören wollen. Wenn du den grundlegenden Ablauf eines System Design Interviews noch nicht kennst, lies zuerst den Pillar-Guide zu System Design Interviews in Deutschland.

Die 10 wichtigsten System Design Patterns🔗

1. Load Balancing🔗

Load Balancing verteilt eingehende Requests auf mehrere Server, damit kein einzelner Server zum Engpass wird. In fast jeder System-Design-Aufgabe ist ein Load Balancer eine der ersten Komponenten, die du einzeichnen solltest, sobald du mehr als einen Application Server hast.

Wie es funktioniert: Ein Load Balancer sitzt zwischen Client und Server-Gruppe. Er empfängt alle eingehenden Requests und leitet sie nach einer bestimmten Strategie weiter. Die gängigsten Strategien sind Round Robin (gleichmäßige Verteilung), Least Connections (der Server mit den wenigsten aktiven Verbindungen bekommt den nächsten Request) und IP Hashing (derselbe Client landet immer beim selben Server).

Wann du es im Interview einsetzen solltest: Sobald du das System über einen einzelnen Server hinaus skalierst. Wenn die Aufgabe Millionen von Nutzern erwähnt, ist Load Balancing praktisch Pflicht. Aber auch bei kleineren Systemen zeigt es dem Interviewer, dass du an Verfügbarkeit denkst, denn ein einzelner Server ist ein Single Point of Failure.

Der Trade-off, den du ansprechen solltest: Load Balancing löst das Problem der Lastverteilung, führt aber Komplexität bei Session-Management ein. Wenn dein Application Server Zustand hält (zum Beispiel eine User-Session), musst du entweder Sticky Sessions verwenden oder den Zustand externalisieren (etwa in Redis). Im Interview reicht es, diesen Punkt zu erwähnen. Du musst ihn nicht im Detail lösen, es sei denn der Interviewer fragt nach.

2. Caching🔗

Caching speichert häufig gelesene Daten in einem schnellen Zwischenspeicher, damit nicht jeder Request die Datenbank trifft. Es ist das Pattern mit dem größten Hebel auf die Performance, und Interviewer erwarten, dass du es in fast jeder Aufgabe irgendwo einbaust.

Wie es funktioniert: Die zwei grundlegenden Strategien sind Cache-Aside (die Anwendung prüft zuerst den Cache, bei einem Miss liest sie aus der Datenbank und schreibt das Ergebnis in den Cache) und Write-Through (jeder Schreibvorgang aktualisiert sowohl Datenbank als auch Cache). Redis und Memcached sind die Tools, die du im Interview nennen solltest.

Wann du es im Interview einsetzen solltest: Immer wenn das Lese-zu-Schreib-Verhältnis hoch ist. Ein URL-Shortener hat zum Beispiel ein Verhältnis von 100:1 (100 Lesezugriffe pro Schreibzugriff). Hier kann ein Cache 90% der Datenbank-Reads eliminieren. Bei einem System mit vielen Schreibzugriffen (etwa ein Logging-System) bringt Caching weniger.

Der Trade-off, den du ansprechen solltest: Cache-Invalidierung ist eines der schwierigsten Probleme in der Informatik. Stale Data, also veraltete Daten im Cache, kann zu inkonsistentem Verhalten führen. Nenne eine konkrete Strategie: TTL (Time-to-Live) für einfache Fälle, Event-basierte Invalidierung für komplexere.

3. Database Sharding🔗

Sharding teilt eine große Datenbank horizontal in kleinere Teile (Shards), die jeweils einen Ausschnitt der Daten halten. Es ist die Antwort auf die Frage „Was machst du, wenn eine einzelne Datenbank die Last nicht mehr bewältigt?”

Wie es funktioniert: Du wählst einen Shard Key, einen Wert, nach dem die Daten aufgeteilt werden. Bei einem User-System könnte das die User-ID sein: Nutzer 1-1.000.000 landen auf Shard A, Nutzer 1.000.001-2.000.000 auf Shard B. Range-based Sharding ist einfach zu verstehen, hat aber das Risiko von Hot Spots (wenn ein Bereich deutlich mehr Traffic hat). Hash-based Sharding verteilt gleichmäßiger, macht aber Range Queries schwieriger.

Wann du es im Interview einsetzen solltest: Wenn die Datenmenge oder die Query-Last eine einzelne Datenbank-Instanz übersteigt. Bei Aufgaben mit Hunderten Millionen von Datensätzen oder Zehntausenden Schreibzugriffen pro Sekunde ist Sharding die Standardantwort.

Der Trade-off, den du ansprechen solltest: Sharding verkompliziert Queries, die über Shard-Grenzen hinweg gehen. JOINs über mehrere Shards sind teuer oder unmöglich. Außerdem ist das Resharding, also das nachträgliche Umverteilen der Daten, ein aufwändiger Prozess. Nenne Consistent Hashing als Strategie, um Resharding-Aufwand zu minimieren.

4. Message Queues🔗

Message Queues entkoppeln Produzenten und Konsumenten von Nachrichten. Statt einen Service synchron aufzurufen und auf die Antwort zu warten, legst du die Nachricht in eine Queue und verarbeitest sie asynchron.

Wie es funktioniert: Ein Producer schreibt eine Nachricht in die Queue (zum Beispiel „Bestellung 12345 wurde aufgegeben”). Ein Consumer liest die Nachricht und verarbeitet sie (zum Beispiel „Sende Bestätigungsmail an den Kunden”). Der Producer muss nicht warten, bis die Mail verschickt wurde. Kafka, RabbitMQ und Amazon SQS sind die Tools, die du kennen solltest.

Wann du es im Interview einsetzen solltest: Immer wenn du asynchrone Verarbeitung brauchst. Klassische Szenarien: E-Mail-Versand, Bildverarbeitung, Benachrichtigungen, Datenverarbeitung im Hintergrund. Auch wenn zwei Services mit unterschiedlicher Geschwindigkeit arbeiten, dient eine Queue als Puffer.

Der Trade-off, den du ansprechen solltest: Message Queues führen Eventual Consistency ein. Die Nachricht ist in der Queue, aber noch nicht verarbeitet. Für Systeme, die sofortige Konsistenz brauchen (zum Beispiel ein Kontostand nach einer Überweisung), ist asynchrone Verarbeitung nicht immer die richtige Wahl. Nenne auch das Risiko von Message Loss und wie du es mit Acknowledgements und Dead-Letter Queues mitigierst.

5. Content Delivery Network (CDN)🔗

Ein CDN verteilt statische Inhalte (Bilder, Videos, CSS, JavaScript) auf Server weltweit, damit Nutzer die Daten vom geografisch nächsten Server laden. Es reduziert Latenz und entlastet den Origin Server.

Wie es funktioniert: Wenn ein Nutzer in München ein Bild anfragt, liefert der CDN-Edge-Server in Frankfurt es aus, statt den Request bis zum Origin Server in Virginia zu schicken. Bei einem Cache-Miss holt der Edge-Server die Datei vom Origin und speichert sie für folgende Requests.

Wann du es im Interview einsetzen solltest: Bei Aufgaben mit globaler Nutzerschaft und statischen Inhalten. Ein Video-Streaming-System, eine Social-Media-Plattform oder ein E-Commerce-Shop sind klassische Szenarien. Auch bei APIs kann ein CDN für häufig aufgerufene, selten ändernde Daten sinnvoll sein.

Der Trade-off, den du ansprechen solltest: CDNs funktionieren am besten für statische oder selten ändernde Inhalte. Für dynamische Daten, die sich pro Nutzer unterscheiden, hilft ein CDN wenig. Außerdem kosten CDNs bei hohem Traffic signifikant, und Cache-Invalidierung bei Content-Updates erfordert eine durchdachte Strategie (Versioned URLs, Cache-Busting Headers).

6. Rate Limiting🔗

Rate Limiting begrenzt die Anzahl der Requests, die ein Client in einem bestimmten Zeitfenster senden darf. Es schützt dein System vor Überlastung und Missbrauch.

Wie es funktioniert: Die gängigsten Algorithmen sind Token Bucket (ein „Eimer” füllt sich mit Tokens in konstantem Tempo, jeder Request verbraucht ein Token), Sliding Window (zählt Requests in einem rollierenden Zeitfenster) und Fixed Window Counter (zählt Requests in fixen Zeitblöcken). Die Implementierung erfolgt typischerweise auf API-Gateway-Ebene.

Wann du es im Interview einsetzen solltest: Bei jeder öffentlichen API. Sobald die Aufgabe eine API erwähnt, die von externen Clients genutzt wird, solltest du Rate Limiting ansprechen. Auch bei internen Services kann es sinnvoll sein, um kaskadierende Fehler zu verhindern.

Der Trade-off, den du ansprechen solltest: Zu aggressives Rate Limiting kann legitime Nutzer aussperren. Zu lockeres Rate Limiting schützt nicht. In verteilten Systemen brauchst du einen zentralen Counter (zum Beispiel in Redis), was wieder eine Netzwerk-Abhängigkeit einführt. Erwähne, dass du unterschiedliche Limits pro Nutzergruppe setzen würdest (Free-Tier vs. Premium).

7. API Gateway🔗

Ein API Gateway ist der zentrale Eintrittspunkt für alle Client-Requests. Es routet Requests an die richtigen Backend-Services, kümmert sich um Authentifizierung, Rate Limiting, Logging und Protokoll-Übersetzung.

Wie es funktioniert: Statt dass der Client direkt mit zehn verschiedenen Microservices kommuniziert, spricht er nur mit dem API Gateway. Das Gateway leitet den Request an den zuständigen Service weiter und aggregiert bei Bedarf Antworten aus mehreren Services.

Wann du es im Interview einsetzen solltest: Sobald dein System mehr als zwei Backend-Services hat. In Microservice-Architekturen ist ein API Gateway praktisch Standard. Es ist auch der natürliche Ort für Rate Limiting, Authentifizierung und Request-Logging.

Der Trade-off, den du ansprechen solltest: Das API Gateway wird zum Single Point of Failure, wenn es nicht redundant betrieben wird. Außerdem kann es zum Bottleneck werden, weil jeder Request durch diesen Punkt muss. Nenne als Lösung horizontale Skalierung des Gateways selbst, kombiniert mit Load Balancing davor.

8. Database Replication🔗

Replication erstellt Kopien deiner Datenbank auf mehreren Servern. Der Zweck: höhere Leseperformance (Lese-Requests werden auf Replicas verteilt) und Ausfallsicherheit (wenn der Primary ausfällt, kann eine Replica übernehmen).

Wie es funktioniert: In einem Primary-Replica-Setup schreibt nur der Primary-Server. Alle Schreibvorgänge werden asynchron (oder synchron) auf die Replicas repliziert. Lese-Requests können von den Replicas bedient werden. Bei einem Primary-Ausfall wird eine Replica zum neuen Primary promoted (Failover).

Wann du es im Interview einsetzen solltest: Sobald Verfügbarkeit ein Thema ist (und das ist es fast immer). Auch wenn du hohe Lese-Last hast, aber der Schreibaufwand moderat bleibt, ist Replication der einfachere erste Schritt vor Sharding.

Der Trade-off, den du ansprechen solltest: Asynchrone Replication führt zu Replication Lag. Ein Nutzer schreibt einen Kommentar, refresht die Seite und sieht ihn nicht, weil der Read von einer Replica kommt, die den Write noch nicht erhalten hat. Read-after-Write-Consistency ist die Lösung: Reads direkt nach einem Write gehen an den Primary statt an eine Replica.

9. Event-Driven Architecture🔗

In einer Event-Driven Architecture kommunizieren Services nicht durch direkte Aufrufe, sondern durch das Publizieren und Konsumieren von Events. Ein Service publiziert „Bestellung erstellt”, und jeder interessierte Service reagiert unabhängig darauf.

Wie es funktioniert: Ein Event Bus (oft Kafka oder ein ähnliches System) ist die zentrale Infrastruktur. Services publizieren Events auf Topics. Andere Services subscriben auf die Topics, die sie interessieren, und verarbeiten die Events unabhängig. Der publizierende Service muss nicht wissen, wer die Events konsumiert.

Wann du es im Interview einsetzen solltest: Bei Aufgaben mit mehreren Services, die auf dasselbe Geschäftsereignis reagieren müssen. Beispiel: Eine Bestellung löst parallel Lagerverwaltung, Rechnungsstellung und Benachrichtigung aus. Auch bei Aufgaben, die Echtzeit-Updates erfordern (Feeds, Dashboards, Live-Tracking), ist Event-Driven Architecture relevant.

Der Trade-off, den du ansprechen solltest: Event-Driven Architecture macht Debugging und Tracing schwieriger, weil die Verarbeitungskette nicht mehr linear ist. Event-Ordering kann zum Problem werden (Was passiert, wenn „Bestellung storniert” vor „Bestellung erstellt” ankommt?). Nenne Correlation IDs für Tracing und idempotente Verarbeitung als Gegenmaßnahmen.

10. Circuit Breaker🔗

Ein Circuit Breaker verhindert, dass ein fehlerhafter Service das gesamte System lahmlegt. Wenn ein Service nicht antwortet, unterbricht der Circuit Breaker die Verbindung, statt immer wieder vergeblich zu versuchen.

Wie es funktioniert: Der Circuit Breaker hat drei Zustände: Closed (alles normal, Requests gehen durch), Open (zu viele Fehler, Requests werden sofort abgelehnt) und Half-Open (nach einer Wartezeit werden einzelne Test-Requests durchgelassen, um zu prüfen, ob der Service wieder funktioniert). Wenn die Test-Requests erfolgreich sind, schließt der Circuit wieder.

Wann du es im Interview einsetzen solltest: Bei Microservice-Architekturen, in denen Services voneinander abhängig sind. Besonders relevant, wenn die Aufgabe Reliability oder Fehlertoleranz betont. Auch bei Systemen mit externen API-Abhängigkeiten (Payment Provider, E-Mail-Service) ist ein Circuit Breaker sinnvoll.

Der Trade-off, den du ansprechen solltest: Ein offener Circuit Breaker bedeutet, dass bestimmte Features temporär nicht verfügbar sind. Du musst eine Fallback-Strategie definieren: Cached Responses zurückgeben, Requests in eine Queue stellen oder dem Nutzer eine sinnvolle Fehlermeldung zeigen. Nenne auch die Schwellenwerte als Konfigurationsherausforderung: Ab wie vielen Fehlern soll der Circuit öffnen?

Patterns im Zusammenspiel: So argumentierst du im Interview🔗

Die zehn Patterns einzeln zu kennen reicht nicht. In einem echten System Design Interview musst du mehrere Patterns kombinieren und erklären, warum du sie in genau dieser Konstellation einsetzt.

Nimm als Beispiel die Aufgabe „Entwirf ein Notification System für 10 Millionen Nutzer”. Eine gute Argumentation sieht so aus:

1. API Gateway als Einstiegspunkt, mit Rate Limiting, damit kein einzelner Client das System flutet
2. Message Queue zwischen API und Notification Workers, weil der Versand asynchron erfolgen kann und die Queue als Puffer bei Lastspitzen dient
3. Database Replication für die Nutzer- und Präferenz-Datenbank, damit Leseoperationen (welche Kanäle hat der Nutzer aktiviert?) schnell sind
4. Caching für Nutzer-Präferenzen, weil sich diese selten ändern, aber bei jedem Notification-Versand gelesen werden
5. Circuit Breaker vor den externen Providern (SMTP-Server, Push-Notification-Service), damit ein Ausfall eines Providers nicht die gesamte Pipeline blockiert

Der Schlüssel ist nicht die Liste, sondern die Begründung. Jedes Pattern löst ein konkretes Problem, das du benennen kannst. Interviewer bei deutschen Unternehmen achten besonders darauf, ob du Over-Engineering vermeidest: Ein Notification System für ein Startup mit 50.000 Nutzern braucht kein Kafka-Cluster mit zehn Partitionen.

Fehler, die du vermeiden solltest🔗

Pattern-Dropping ohne Kontext🔗

Der verbreitetste Fehler: Kandidaten zeichnen ein Diagramm und verteilen Patterns wie Buzzwords. „Hier kommt ein Cache, dort ein Load Balancer, und natürlich eine Message Queue.” Ohne zu erklären, welches Problem jede Komponente löst, wirkt das auf den Interviewer wie auswendig gelernt statt verstanden.

Die Gegenmaßnahme ist einfach: Bevor du ein Pattern einzeichnest, sage einen Satz darüber, welches Problem du damit löst. „Die Datenbank bekommt 50.000 Lesezugriffe pro Sekunde, davon betreffen 80% die Top-1000-URLs. Ein Redis-Cache vor der Datenbank kann diese 80% abfangen und die DB-Last auf 10.000 QPS reduzieren.” Das dauert zehn Sekunden und macht den Unterschied.

Over-Engineering für ein Startup🔗

Deutsche Mittelständler und Startups suchen pragmatische Developer. Wenn die Aufgabe sagt „50.000 Nutzer”, dann brauchst du keinen Multi-Region-Setup mit Global CDN und Sharding über 20 Datenbank-Knoten. Beginne mit dem einfachsten Design, das funktioniert, und skaliere erst, wenn die Anforderungen es erfordern. Das zeigt dem Interviewer, dass du reale Systeme gebaut hast und nicht nur Lehrbuch-Architekturen kennst.

Trade-offs ignorieren🔗

Jedes Pattern hat eine Kehrseite. Caching führt zu Stale Data. Message Queues führen zu Eventual Consistency. Sharding verkompliziert Queries. Wenn du nur Vorteile nennst, entsteht der Eindruck, dass du die Konsequenzen nicht durchdacht hast. Nenne zu jedem Pattern mindestens einen Trade-off und erkläre, warum du ihn in diesem Kontext akzeptierst.

Patterns verwechseln oder falsch zuordnen🔗

Replication ist nicht Sharding. Ein CDN ist kein Cache (obwohl es Caching nutzt). Ein API Gateway ist kein Load Balancer (obwohl es Load Balancing enthalten kann). Verwende die Begriffe präzise. Wenn du dir bei einer Abgrenzung unsicher bist, sprich es offen an: „Ich verwende hier Replication für Ausfallsicherheit, nicht für Datenteilung, dafür bräuchten wir Sharding.”

Nächster Schritt🔗

Diese zehn Patterns bilden das Fundament, auf dem du jede System Design Aufgabe aufbauen kannst. Das Wissen allein reicht aber nicht. Der Unterschied zwischen „ich kenne die Patterns” und „ich kann sie im Interview einsetzen” liegt in der Übung: laut denken, unter Zeitdruck argumentieren, auf Rückfragen reagieren.

CodingCareers Mock System Design Interviews simulieren genau diese Situation. Du bearbeitest eine realistische Aufgabe mit einem erfahrenen Developer als Interviewer, der dir konkretes Feedback zu deiner Pattern-Auswahl, deiner Argumentation und deiner Kommunikation gibt. Kein Lehrbuch-Feedback, sondern Feedback von jemandem, der selbst System Design Interviews in deutschen Tech-Unternehmen geführt und bestanden hat.

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