Systemdesign
Vergleicht Architekturdenken, Trade-off-Analyse und die Qualität des Systemdesigns.
In diesem Genre werden vor allem Faehigkeiten wie Architekturqualitat, Vollstandigkeit, Trade-off-Analyse betrachtet.
Anders als coding gewichtet dieses Genre Architektur, Skalierung, Zuverlaessigkeit und Trade-offs staerker als lauffaehige Implementierungsdetails.
Ein hoher Wert hier bedeutet nicht, dass das Modell auch den besten funktionierenden Code oder die einfachste Erklaerung liefert.
Wofuer starke Modelle in diesem Genre gut geeignet sind
Architekturvorschlaege, Servicedesign und Diskussionen ueber Skalierbarkeit.
Was dieses Genre allein nicht zeigen kann
Qualitaet der Low-Level-Implementierung, exakte Korrektheit oder Schreiben fuer nichttechnisches Publikum.
Systemdesign: GPT-5 und Anthropic drängen sich an der Spitze, Gemini fällt zurück
OpenAI
Anthropic
OpenAI
Durchschnittswert je Modell
Gewichtung
Über 35 bewertete Design-Antworten bildet die Spitze ein enges Cluster aus GPT-5 und Anthropic. GPT-5.5 (8,91) und Claude Opus 4.8 (8,69) belegen die Plätze 1 und 2 mit makelloser Bilanz, jeweils aber auf einer einzigen Stichprobe – also eher vielversprechend als gesichert. Die am besten belegten Spitzenergebnisse sind GPT-5.4 (8,67 über 5 Stichproben, 60 % Siegquote) und GPT-5 mini (8,43 über 4 Stichproben, 75 % Siegquote), die hier am stärksten ins Gewicht fallen.
Durchschnitt und Rang weichen ab: GPT-5.4 übertrifft GPT-5 mini im Schnitt (8,67 vs. 8,43), liegt aber dahinter, weil GPT-5 mini einen höheren Anteil seiner Duelle gewinnt (75 % vs. 60 %). Claude Sonnet 4.6 (8,53, 60 % über 5) gehört genau zu dieser Gruppe, sodass die ersten sechs in der Qualität weniger als einen halben Punkt auseinanderliegen und sich vor allem über direkte Siege ordnen.
Die Gemini-Reihe bildet eine klare untere Stufe: 2.5 Pro (7,51), Flash (7,41) und Flash-Lite (7,12) gewinnen keines ihrer Duelle und liegen 1,2 bis 1,8 Punkte hinter den Spitzenreitern. Da Architekturqualität mit 30 am höchsten gewichtet ist und Abwägungsbegründung sowie Skalierbarkeit je 20, deutet der Abstand auf schwächeres Denken über Struktur und Kompromisse hin, nicht auf die Darstellung.
Die Stichprobengrößen reichen von 1 bis 6 je Modell, daher ist die Feinordnung innerhalb des 8-Punkte-Clusters vorläufig und wenige Prompts können jeden Schnitt verschieben. Die Spanne von 1,79 Punkten zwischen Erstem und Letztem ist real, doch es sind bedingungsabhängige Messwerte für Design-Prompts, kein universelles Urteil.
Fazit
Für Systemdesign ist GPT-5 mini die am besten begründbare Alltagswahl (75 % Siegquote über 4 Stichproben), mit GPT-5.4 als am besten belegter Oberklasse-Option (8,67 über 5). Claude Sonnet 4.6 ist qualitativ praktisch gleichauf; die Gemini-Reihe liegt in diesem Genre klar zurück.
Diese Analyse basiert auf den von Orivel gemessenen Benchmark-Werten fuer dieses Genre und wird regelmaessig aktualisiert. Die Werte sind bedingungsabhaengige Messungen, keine absolute Wahrheit.
Ranking starker Modelle in diesem Genre
Dieses Ranking ist nach dem Durchschnittsscore nur innerhalb dieses Genres sortiert.
Zuletzt aktualisiert: 30 May 2026 09:41
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
| Gerankte Modelle | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.5 | OpenAI |
100%
|
89
|
1 | 1 | Bewertung und Punktzahl von GPT-5.5 ansehen |
| #2 | Claude Opus 4.8 NEU | Anthropic |
100%
|
87
|
1 | 1 | Bewertung und Punktzahl von Claude Opus 4.8 ansehen |
| #3 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Bewertung und Punktzahl von GPT-5 mini ansehen |
| #4 | GPT-5.4 | OpenAI |
60%
|
87
|
3 | 5 | Bewertung und Punktzahl von GPT-5.4 ansehen |
| #5 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Bewertung und Punktzahl von Claude Sonnet 4.6 ansehen |
| #6 | Claude Haiku 4.5 | Anthropic |
40%
|
82
|
2 | 5 | Bewertung und Punktzahl von Claude Haiku 4.5 ansehen |
| #7 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Bewertung und Punktzahl von Gemini 2.5 Pro ansehen | |
| #8 | Gemini 2.5 Flash |
0%
|
74
|
0 | 6 | Bewertung und Punktzahl von Gemini 2.5 Flash ansehen | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | Bewertung und Punktzahl von Gemini 2.5 Flash-Lite ansehen |
Was in Systemdesign bewertet wird
Kriterien und Gewichte fuer dieses Genre-Ranking.
Architekturqualitat
30.0%
Dieses Kriterium ist enthalten, um Architekturqualitat in der Antwort zu pruefen. Es hat mehr Gewicht, weil dieser Teil das Gesamtergebnis in diesem Genre stark praegt.
Vollstandigkeit
20.0%
Dieses Kriterium ist enthalten, um Vollstandigkeit in der Antwort zu pruefen. Es hat ein klares Gewicht, weil es die Qualitaet sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Trade-off-Analyse
20.0%
Dieses Kriterium ist enthalten, um Trade-off-Analyse in der Antwort zu pruefen. Es hat ein klares Gewicht, weil es die Qualitaet sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Skalierbarkeit und Zuverlassigkeit
20.0%
Dieses Kriterium ist enthalten, um Skalierbarkeit und Zuverlassigkeit in der Antwort zu pruefen. Es hat ein klares Gewicht, weil es die Qualitaet sichtbar beeinflusst, auch wenn es nicht alles bestimmt.
Klarheit
10.0%
Dieses Kriterium ist enthalten, um Klarheit in der Antwort zu pruefen. Es ist leichter gewichtet, weil es das Hauptziel unterstuetzt, das Genre aber nicht allein definiert.
Aktuelle Aufgaben
Systemdesign
Entwerfen Sie ein Echtzeit-kollaboratives Whiteboard-System
Sie sollen die Hochniveau-Systemarchitektur für eine Echtzeit-kollaborative Whiteboard-Anwendung entwerfen. **Kernanforderungen:** 1. **Echtzeit-Kollaboration:** Mehrere Benutzer (bis zu 100 pro Sitzung) können einem einzelnen Whiteboard beitreten und die Aktionen der anderen (Zeichnen, Text hinzufügen, Objekte verschieben) in nahezu Echtzeit (unter 200 ms Latenz) sehen. 2. **Persistenz:** Whiteboard-Sitzungen müssen gespeichert werden, damit Benutzer die Anwendung schließen und später an ihrer Arbeit anknüpfen können. 3. **Werkzeuge:** Benutzer sollten grundlegende Werkzeuge wie Freihandstift, Textfelder und Haftnotizen haben. **Skalierungs- und Zuverlässigkeitsanforderungen:** * Unterstützung von bis zu 10.000 gleichzeitig aktiven Whiteboard-Sitzungen. * Unterstützung von bis zu 1.000.000 Gesamtnutzern. * Der Dienst muss hochverfügbar sein, mit 99,9 % Betriebszeit. **Ihre Aufgabe:** Liefern Sie ein Systemdesign, das die obigen Anforderungen erfüllt. Ihre Antwort sollte Folgendes abdecken: 1. **High-Level-Architektur:** Ein Diagramm oder eine Beschreibung der Hauptkomponenten (z. B. Clients, Load Balancer, Anwendungsserver, Datenbanken, Echtzeitdienste) und wie sie miteinander interagieren. 2. **Echtzeit-Kommunikation:** Erklären Sie die Technologie und das Protokoll, die Sie verwenden würden, um Aktualisierungen an alle Benutzer in einer Sitzung zu übertragen. 3. **Datenmodell:** Beschreiben Sie, wie Sie die Daten für ein Whiteboard, dessen Inhalte (Zeichnungen, Text usw.) und Benutzersitzungen strukturieren würden. 4. **Skalierbarkeits- und Zuverlässigkeitsstrategie:** Wie würden Sie das System entwerfen, um die Zielbelastung zu bewältigen und eine hohe Verfügbarkeit sicherzustellen? 5. **Kompromisse:** Diskutieren Sie einen wesentlichen Kompromiss, den Sie in Ihrem Design gemacht haben (z. B. Konsistenz vs. Latenz, Wahl der Datenbank usw.).
Systemdesign
Entwurf eines skalierbaren Ticketreservierungssystems für Konzerte
Entwerfe ein System für eine Online-Plattform zum Verkauf von Konzerttickets. Benutzer können Veranstaltungen durchsuchen, Sitzplatzverfügbarkeit einsehen, spezifische Sitzplätze für 10 Minuten reservieren, über einen externen Zahlungsanbieter bezahlen und ein digitales Ticket erhalten. Die Plattform läuft in einer Cloud-Region über mehrere Availability Zones. Explizite Einschränkungen: 3 Millionen registrierte Benutzer, 500.000 täglich aktive Benutzer, bei großen Verkaufsstarts können 150.000 gleichzeitige Benutzer auftreten, Spitzenlast sind 8.000 Sitzplatzreservierungsversuche pro Sekunde und 2.000 Zahlungsversuche pro Sekunde, jede Veranstaltung hat bis zu 60.000 Sitzplätze, das System darf niemals denselben Sitzplatz zweimal verkaufen, Sitzplatzreservierungen verfallen nach 10 Minuten, wenn nicht bezahlt, p95-Latenz für Browsing und Sitzplan-Abfragen sollte unter 300 ms liegen, p95-Latenz für Reservierungsbestätigung sollte unter 800 ms liegen (ohne Zeit des Zahlungsanbieters), Verfügbarkeitsziel während Verkaufsfenstern ist 99,95 %, Recovery Point Objective (RPO) unter 1 Minute, Recovery Time Objective (RTO) unter 15 Minuten, und Callback-Nachrichten des Zahlungsanbieters sind mindestens einmal (at-least-once), können außer Reihenfolge ankommen und können um bis zu 5 Minuten verzögert eintreffen. Lege einen Entwurfsplan vor. Beinhaltet die Hauptdienste und Datenspeicher, die Kern-APIs, das Datenmodell für Sitzplätze und Reservierungen, den Anfragefluss für Browsen, Reservieren, Bezahlen und Ablauf von Reservierungen, die Skalierungsstrategie für Verkehrsspitzen, Vorgehen zur Zuverlässigkeit und Disaster Recovery, Konsistenzentscheidungen, die Überschneidungen beim Verkauf verhindern, Monitoring und Alerting sowie die wichtigsten Abwägungen oder Alternativen, die du in Betracht gezogen hast. Nenne alle vernünftigen Annahmen, die du triffst.
Systemdesign
Entwerfen Sie einen skalierbaren Benachrichtigungsdienst
Sie sind Senior-Softwareingenieur in einem schnell wachsenden Social-Media-Unternehmen. Ihre Aufgabe ist es, einen skalierbaren und zuverlässigen Benachrichtigungsdienst zu entwerfen. Dieser Dienst ist dafür verantwortlich, Benachrichtigungen an Nutzer über verschiedene Ereignisse zu senden, wie z. B. neue Follower, Likes für ihre Beiträge, Kommentare und Direktnachrichten.
Systemdesign
Entwurf eines Echtzeit-Benachrichtigungsdienstes
Skizzieren Sie ein hochrangiges Systemdesign für einen Echtzeit-Benachrichtigungsdienst für eine Social-Media-Plattform. Der Dienst muss die folgenden Anforderungen erfüllen: - **Skalierung:** 10 Millionen tägliche aktive Nutzer (DAU). - **Volumen:** Jeder Nutzer erhält im Durchschnitt 20 Benachrichtigungen pro Tag. - **Latenz:** Benachrichtigungen müssen innerhalb von unter 2 Sekunden an das Gerät des Nutzers zugestellt werden. - **Kanäle:** Unterstützung für Push-Benachrichtigungen (mobil), E‑Mail und In-App-Benachrichtigungen. - **Zuverlässigkeit:** 99,9% Verfügbarkeit und kein Verlust von Benachrichtigungsdaten. Ihr Entwurf sollte die folgenden Aspekte abdecken: 1. **Kernarchitektur:** Beschreiben Sie die Schlüsselkomponenten (z. B. API-Gateway, Benachrichtigungsdienst, Nachrichtenwarteschlange, Worker) und deren Interaktionen. 2. **Datenbankschema:** Schlagen Sie ein grundlegendes Datenbankschema zur Speicherung von Benutzerbenachrichtigungen und -präferenzen vor. 3. **Skalierungsstrategie:** Erklären Sie, wie Sie das System skalieren würden, um die angegebene Last und zukünftiges Wachstum zu bewältigen. 4. **Zuverlässigkeit und Fehlertoleranz:** Erläutern Sie die Maßnahmen, die Sie ergreifen würden, um hohe Verfügbarkeit sicherzustellen und Datenverlust zu verhindern. 5. **Wesentliche Abwägungen:** Diskutieren Sie mindestens zwei bedeutende Abwägungen, die Sie in Ihrem Design getroffen haben (z. B. Konsistenz vs. Verfügbarkeit, Wahl der Datenbank, Push- vs. Pull-Modell).
Systemdesign
Entwerfen Sie einen URL-Verkürzungsdienst
Entwerfen Sie einen URL-Verkürzungsdienst (ähnlich wie bit.ly oder tinyurl.com), der die folgenden Einschränkungen erfüllen muss: 1. Der Dienst muss 100 Millionen neue URL-Verkürzungen pro Monat unterstützen. 2. Das durchschnittliche Lese-zu-Schreib-Verhältnis beträgt 100:1 (d. h. verkürzte URLs werden wesentlich häufiger aufgerufen als erstellt). 3. Verkürzte URLs müssen mindestens 5 Jahre nach ihrer Erstellung zugänglich bleiben. 4. Das System muss eine Verfügbarkeit von 99,9% erreichen. 5. Die Redirect-Latenz (vom Empfang einer Kurz-URL-Anfrage bis zum Ausgeben des HTTP-Redirects) muss unter 50 ms beim 95. Perzentil liegen. Behandeln Sie in Ihrem Entwurf alle folgenden Punkte: A. Architektur auf hoher Ebene: Beschreiben Sie die Hauptkomponenten (API-Server, Datenbanken, Caches, Load Balancer usw.) und wie sie miteinander interagieren. Fügen Sie eine klare Beschreibung des Anfrageflusses sowohl für die URL-Erstellung als auch für die URL-Weiterleitung bei. B. Strategie zur Erzeugung kurzer URLs: Erklären Sie, wie Sie eindeutige Kurz-Codes erzeugen würden. Diskutieren Sie die Abwägungen zwischen verschiedenen Ansätzen (z. B. Hashing, zählerbasiert, vorab generierte Schlüssel-Pools) und begründen Sie Ihre Wahl. C. Datenspeicherung: Wählen Sie eine Datenbanktechnologie und ein Schema. Schätzen Sie die Speicheranforderungen über 5 Jahre unter Berücksichtigung der Einschränkungen. Erklären Sie, warum Ihre gewählte Datenbank geeignet ist. D. Skalierungsstrategie: Erklären Sie, wie das System skaliert, um das leseintensive Verkehrsverhalten zu bewältigen. Diskutieren Sie Caching-Strategie, Datenbank-Partitionierung oder Sharding-Ansatz und wie Sie mit Hot Keys (virale URLs, die überproportionalen Traffic erhalten) umgehen. E. Zuverlässigkeit und Fehlertoleranz: Beschreiben Sie, wie das System die Verfügbarkeit von 99,9% aufrechterhält. Gehen Sie darauf ein, was passiert, wenn einzelne Komponenten ausfallen, und wie Sie Datenreplikation und Failover handhaben. F. Wichtige Abwägungen: Identifizieren Sie mindestens zwei bedeutende Design-Abwägungen, die Sie getroffen haben, und erklären Sie, warum Sie angesichts der angegebenen Einschränkungen eine Seite der Abwägung der anderen vorgezogen haben.
Systemdesign
Entwurf eines URL-Kürzungsdienstes
Entwerfen Sie einen URL-Kürzungsdienst (ähnlich wie bit.ly oder tinyurl.com), der die folgenden Einschränkungen erfüllen muss: 1. Der Dienst muss 100 Millionen neue URL-Kürzungen pro Monat unterstützen. 2. Das Verhältnis von Lese- (Redirect-) Anfragen zu Schreib- (Kurz-URL-Erstellungs-) Anfragen beträgt 100:1. 3. Die gekürzten URLs sollten so kurz wie möglich sein, müssen aber das erwartete Volumen für mindestens 10 Jahre unterstützen. 4. Das System muss eine Verfügbarkeit von 99,9 % Uptime erreichen. 5. Die Redirect-Latenz muss unter 50 ms beim 95. Perzentil liegen. 6. Der Dienst muss einen sanften Abbau (graceful degradation) handhaben, falls ein Rechenzentrum offline geht. Gehen Sie in Ihrem Entwurf auf jeden der folgenden Bereiche ein: A) API-Design: Definieren Sie die wichtigsten API-Endpunkte und deren Verträge. B) Datenmodell und Speicherung: Wählen Sie eine Speicherlösung, begründen Sie Ihre Wahl, erklären Sie Ihr Schema und schätzen Sie den insgesamt benötigten Speicher über 10 Jahre. C) Short-URL-Generierung: Beschreiben Sie Ihren Algorithmus zur Erzeugung kurzer Codes. Erörtern Sie, wie Sie Kollisionen vermeiden, welchen Zeichensatz und welche Länge Sie gewählt haben, mit einer mathematischen Begründung, warum der Schlüsselraum ausreichend ist. D) Skalierung und Performance: Erklären Sie, wie Sie Lese- und Schreibvorgänge unabhängig skalieren würden. Beschreiben Sie Ihre Caching-Strategie, einschließlich Cache-Eviktionsrichtlinie und erwarteter Trefferquote. Erklären Sie, wie Sie die Anforderung von 50 ms p95-Latenz erfüllen. E) Zuverlässigkeit und Fehlertoleranz: Beschreiben Sie, wie das System Ausfälle von Rechenzentren handhabt, Ihre Datenreplikationsstrategie und welche Kompromisse Sie zwischen Konsistenz und Verfügbarkeit eingehen (beziehen Sie sich auf das CAP-Theorem). F) Trade-off-Diskussion: Identifizieren Sie mindestens zwei wesentliche Design-Trade-offs, die Sie getroffen haben, und erklären Sie, warum Sie eine Option gegenüber einer anderen gewählt haben, einschließlich dessen, was Sie opfern und gewinnen würden. Präsentieren Sie Ihre Antwort als einen strukturierten Plan mit klaren Abschnitten, die A bis F entsprechen.