Was System Design ist

Wer programmieren kann, kann Funktionen schreiben, Seiten bauen und Daten speichern. System Design ist die Fähigkeit, eine Software als Ganzes zu entwerfen: welche Komponenten es gibt, wie Daten zwischen ihnen fließen, wo sie gespeichert werden, was passiert, wenn etwas ausfällt, und wie das Ganze betrieben wird. Dabei geht es fast nie um die eine richtige Lösung, sondern um Abwägungen zwischen mehreren Zielen, die sich gegenseitig im Weg stehen: Korrektheit, Geschwindigkeit, Verfügbarkeit, Sicherheit, Kosten, Wartbarkeit und das Tempo, in dem ein Team Neues ausliefern kann.

Diese Fähigkeit gewinnt gerade stark an Bedeutung. KI-Werkzeuge schreiben heute in Minuten Code, für den man früher Tage brauchte. Sie entscheiden aber nicht, wem welche Daten gehören, was bei einem Ausfall passieren soll, welche Sicherheitsgrenzen gelten oder was der Betrieb im Monat kosten darf. Je schneller Code entsteht, desto wichtiger wird es, ihn in ein verständliches Gesamtsystem einzuordnen und falsche Annahmen früh zu erkennen.

1. Was System Design ist – und was nicht

Genauso wichtig ist, was System Design nicht ist. Es ist keine Sammlung von Cloud-Logos und kein Auswendiglernen einer Standardarchitektur für jede Aufgabe. Es ist nicht gleichbedeutend mit Microservices oder Kubernetes. Es ist keine einmalige Planungsphase vor dem Programmieren, sondern begleitet ein System über seine ganze Lebenszeit. Und es ist nicht nur für Anwendungen mit Millionen Nutzern relevant. Auch eine kleine Anwendung braucht bewusste Entscheidungen: Bei tausend Nutzern können Datenschutz, Backups oder Zahlungsdaten wichtiger sein als horizontale Skalierung. Bei einer internen Anwendung kann die Änderbarkeit wichtiger sein als maximale Verfügbarkeit.

2. Die Bausteine einer Webanwendung

Fast jede Webanwendung besteht aus denselben Grundbausteinen, auch wenn sie unterschiedlich groß und unterschiedlich verteilt sind. Klicken Sie sich durch den typischen Weg einer Anfrage:

In einer kleinen Anwendung laufen viele dieser Bausteine auf einem einzigen Server oder sind ganz weggelassen. Eine Terminbuchung für einen Friseursalon braucht vermutlich weder Queue noch Cache; eine Datenbank, eine Anwendung und ein ordentliches Backup genügen. Eine Lernplattform mit Tausenden gleichzeitigen Nutzern, KI-Funktionen und Audioverarbeitung braucht dagegen fast alle Bausteine. Die Kunst liegt darin, zu erkennen, welche Bausteine für welche Anforderung nötig sind – und welche nur Komplexität hinzufügen.

3. Der Designprozess

Ob in einem Kundenprojekt, bei einem eigenen Produkt oder in einem Vorstellungsgespräch: Ein fester Ablauf verhindert, dass man zu früh in Details springt. Bewährt haben sich sechs Schritte.

Die Schritte bauen aufeinander auf. Wer ohne klare Anforderungen eine Architektur zeichnet, entwirft ein System für ein Problem, das niemand hat. Wer ohne Schätzung über Skalierung spricht, weiß nicht, ob er für hundert oder hunderttausend Nutzer plant. Und wer ohne Datenmodell über Datenbanken entscheidet, entscheidet ins Blaue. Die folgenden Lektionen dieses Moduls vertiefen die ersten Schritte: Anforderungen klären, Last schätzen und den passenden Architekturstil wählen.

4. Abwägungen statt perfekter Lösungen

Es gibt keine Architektur, die gleichzeitig maximal konsistent, immer verfügbar, extrem billig, weltweit schnell und leicht zu ändern ist. System Design bedeutet, begründete Prioritäten zu setzen. Ein hilfreiches Muster für jede Entscheidung hat vier Teile: die Anforderung, die erfüllt werden soll, die gewählte Entscheidung, die Kosten in Form von Nachteilen oder neuen Risiken und die Prüfung, also die Metrik oder der Test, der zeigt, ob die Entscheidung funktioniert.

Ein Beispiel aus einem Onlineshop: Produktseiten werden 60 Sekunden im Cache gehalten, damit die Datenbank in Spitzenzeiten entlastet wird. Dafür können Bestandsanzeigen kurz veraltet sein. Der Bezahlvorgang liest den Bestand deshalb immer direkt aus der Datenbank und reserviert ihn in einer Transaktion. Überwacht werden die Trefferquote des Caches, die Antwortzeit der Datenbank und fehlgeschlagene Reservierungen. Dieser Satz ist ein vollständiges, überprüfbares Stück System Design – ganz ohne Diagramm.

5. Das Ziel dieses Kurses

Nach diesem Kurs sollten Sie ein System in 45 bis 60 Minuten strukturiert entwerfen können. Das bedeutet konkret: funktionale und nicht-funktionale Anforderungen präzisieren, Last, Speicher und Kosten grob abschätzen, Schnittstellen und Datenmodelle aus Geschäftsabläufen ableiten, Datenbank, Cache, Warteschlange und Objektspeicher begründet auswählen, Konsistenz, Verfügbarkeit und Latenz als konkrete Abwägungen erklären, Zeitüberschreitungen, Wiederholungen und Idempotenz richtig planen, Beobachtbarkeit, Sicherheit und Deployment von Anfang an einbeziehen und Entscheidungen verständlich dokumentieren.

Der Kurs ist in neun Module gegliedert. Nach diesen Grundlagen folgen die technischen Fundamente wie Netzwerke und Nebenläufigkeit, dann Datenhaltung, Skalierung, Zuverlässigkeit und Betrieb, Schnittstellen und Sicherheit, der Entwurf von KI-Systemen und moderne Anwendungsmuster wie Echtzeit und Offline-Betrieb. Den Abschluss bilden Fallstudien, in denen Sie das Gelernte an konkreten Aufgaben anwenden – vom Kurzlink-Dienst bis zur KI-Lernplattform. Wer Anwendungen bereits entwickelt, etwa mit React, Node.js oder Python, wird viele Konzepte wiedererkennen und lernt, sie bewusst und begründet einzusetzen.

Ein letzter Hinweis zur Arbeitsweise: System Design lernt man nicht durch Lesen allein. Die wirksamste Übung ist, eigene Anwendungen mit den Fragen dieses Kurses zu betrachten. Wo liegt die Quelle der Wahrheit? Was passiert, wenn die Datenbank fünf Minuten nicht erreichbar ist? Welche Anfrage ist die teuerste? Wer diese Fragen regelmäßig stellt, entwickelt nach und nach das Gespür, das gute Architekten auszeichnet – und erkennt Probleme, bevor sie im Betrieb auftreten.

Wer diesen Blick einübt, stellt schnell fest, dass die meisten Probleme im Betrieb nicht an exotischen Stellen entstehen, sondern an den Übergängen zwischen Bausteinen: eine Datenbank, die unter Last langsamer antwortet, eine externe Schnittstelle ohne Zeitlimit, ein Hintergrundjob, der doppelt läuft. Genau diese Übergänge stehen deshalb in den folgenden Modulen immer wieder im Mittelpunkt.

Nehmen Sie sich zum Einstieg eine Anwendung vor, die Sie gut kennen – ein eigenes Projekt oder eine Software aus dem Arbeitsalltag – und zeichnen Sie ihre Bausteine auf ein Blatt Papier. Welche Bausteine aus dem Explorer finden Sie wieder, welche fehlen, und welche wären vielleicht gar nicht nötig? Diese einfache Übung schärft den Blick für alles, was in den folgenden Modulen kommt, und macht die abstrakten Begriffe sofort greifbar. Heben Sie die Skizze auf – am Ende des Kurses werden Sie sie mit ganz anderen Augen betrachten.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.