Systemdesign
Entdecke, wie KI-Modelle in Systemdesign performen. Vergleiche Rankings, Bewertungskriterien und aktuelle Benchmark-Beispiele.
Genre-Uberblick
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.
Ranking starker Modelle in diesem Genre
Dieses Ranking ist nach dem Durchschnittsscore nur innerhalb dieses Genres sortiert.
Zuletzt aktualisiert: 22 Mar 2026 21:21
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
Siegesquote
Durchschnittsscore
| Gerankte Modelle | Detail | ||||||
|---|---|---|---|---|---|---|---|
| #1 | GPT-5.2 | OpenAI |
100%
|
90
|
3 | 3 | Bewertung und Punktzahl von GPT-5.2 ansehen |
| #2 | GPT-5.4 | OpenAI |
100%
|
89
|
3 | 3 | Bewertung und Punktzahl von GPT-5.4 ansehen |
| #3 | Claude Opus 4.6 | Anthropic |
100%
|
87
|
3 | 3 | Bewertung und Punktzahl von Claude Opus 4.6 ansehen |
| #4 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | Bewertung und Punktzahl von GPT-5 mini 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 |
50%
|
84
|
2 | 4 | 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 | 5 | Bewertung und Punktzahl von Gemini 2.5 Flash ansehen | |
| #9 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | 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
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.
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 Lese-zu-Schreib-Verhältnis beträgt 100:1 (d. h. für jede erstellte URL wird sie durchschnittlich 100-mal aufgerufen). 3. Verkürzte URLs müssen mindestens 5 Jahre lang zugänglich bleiben. 4. Das System muss eine Verfügbarkeit von 99,9 % erreichen. 5. Weiterleitungs-Latenz (vom Eintreffen einer Kurz-URL-Anfrage bis zum Ausgeben des HTTP-Redirects) muss unter 50 ms im 95. Perzentil liegen. Ihr Entwurf sollte alle der folgenden Bereiche behandeln: A. **Strategie zur Generierung kurzer URLs**: Wie werden Sie eindeutige, kompakte Kurz-Codes erzeugen? Diskutieren Sie das Codierungsschema, die erwartete URL-Länge und wie Sie Kollisionen oder die Erschöpfung des Schlüsselraums behandeln. B. **Datenspeicherung**: Welche Datenbank(en) werden Sie verwenden und warum? Schätzen Sie den Gesamtspeicherbedarf über 5 Jahre. Erklären Sie Ihr Schema-Design sowie jede Partitionierungs- oder Sharding-Strategie. C. **Lesepfad-Architektur**: Wie werden Sie Weiterleitungsanfragen in großem Umfang bedienen, um die Latenz- und Durchsatzanforderungen zu erfüllen? Diskutieren Sie Caching-Ebenen, CDN-Einsatz und Replikationsstrategien. D. **Schreibpfad-Architektur**: Wie gehen Sie zuverlässig mit der Aufnahme von 100M neuen URLs pro Monat um? Diskutieren Sie eventuelle Queuing-, Rate-Limiting- oder Konsistenzüberlegungen. E. **Zuverlässigkeit und Fehlertoleranz**: Wie geht Ihr System mit Knotenfehlern, Ausfällen von Rechenzentren oder Cache-Invalidierung um? Wie sieht Ihre Backup- und Wiederherstellungsstrategie aus? F. **Wesentliche Kompromisse**: Identifizieren Sie mindestens zwei bedeutende Abwägungen in Ihrem Design (z. B. Konsistenz vs. Verfügbarkeit, Speicherkosten vs. Leseleistung, Einfachheit vs. Skalierbarkeit) und erklären Sie, warum Sie sich für die jeweilige Seite entschieden haben. Stellen Sie Ihre Antwort als strukturiertes Designdokument mit klaren Abschnitten entsprechend A bis F oben dar.
Systemdesign
Entwerfen Sie einen globalen URL-Verkürzungsdienst
Entwerfen Sie einen öffentlichen URL-Verkürzungsdienst ähnlich wie Bitly. Benutzer sollen eine lange URL einreichen und einen kurzen Alias erhalten können; beim Aufrufen des Kurzlinks soll schnell zur ursprünglichen URL weitergeleitet werden. Das System muss benutzerdefinierte Aliase, optionale Ablaufdaten, grundlegende Klick-Analysen und Maßnahmen zur Missbrauchsbekämpfung für bösartige Links unterstützen. Anforderungen und Einschränkungen: - Funktionale Anforderungen: - Kurz-URLs für lange URLs erstellen. - Kurz-URLs auf die Original-URLs weiterleiten. - Benutzergesteuerte (custom) Aliase unterstützen, wenn verfügbar. - Optionale Ablaufzeit pro Link unterstützen. - Klickereignisse für Analytics aufzeichnen. - Benutzern erlauben, einen Link manuell zu deaktivieren. - Skalierungsannahmen: - 120 Millionen neue Kurz-URLs pro Monat. - 1,5 Milliarden Weiterleitungen pro Tag. - Weiterleitungsverkehr ist global verteilt und leseintensiv. - Analysedaten sollten innerhalb von 15 Minuten abfragbar sein. - Leistungsziele: - Weiterleitungs-p95-Latenz unter 80 ms für die meisten Regionen. - Erstellung von Short-Links p95 unter 300 ms. - 99.99% Verfügbarkeit für Weiterleitungen. - Daten und Aufbewahrung: - Links können unbegrenzt existieren, sofern sie nicht ablaufen oder deaktiviert werden. - Roh-Klickereignisse können 90 Tage aufbewahrt werden; aggregierte Analytics für 2 Jahre. - Betriebliche Einschränkungen: - Verwenden Sie Standard-Cloud-Infrastruktur; gehen Sie nicht davon aus, dass ein einziges exotisches Managed-Produkt alles löst. - Budget ist wichtig: Begründen Sie jede Wahl für Replikation, Caching und Speicherung. - Kurzcodes sollten kompakt und in großem Maßstab einigermaßen schwer zu erraten sein, aber perfekte Geheimhaltung ist nicht erforderlich. Geben Sie in Ihrer Antwort Folgendes an: 1. Eine Architektur auf hoher Ebene mit Hauptkomponenten und Datenfluss. 2. Speicherentscheidungen für Link-Metadaten, Weiterleitungsweg und Analytics-Ereignisse mit Begründung. 3. Eine Strategie zur Short-Code-Generierung, einschließlich Vermeidung von Kollisionen und Umgang mit benutzerdefinierten Aliasen. 4. Einen Skalierungsplan für globalen Traffic, einschließlich Caching, Partitionierung/Sharding und Multi-Region-Überlegungen. 5. Einen Zuverlässigkeitsplan, der Ausfälle, Hot-Keys, Katastrophenwiederherstellung und Verhalten im degradierten Modus abdeckt. 6. Wichtige APIs und Kerndatenmodelle. 7. Maßnahmen zur Missbrauchsbekämpfung und Sicherheitsüberlegungen. 8. Die wichtigsten Abwägungen, die Sie getroffen haben, und warum.
Systemdesign
Entwerfen Sie einen globalen URL-Kürzungsdienst
Entwerfen Sie einen global verfügbaren URL-Kürzungsdienst ähnlich Bitly. Der Dienst muss Nutzern erlauben, Kurzlinks zu erstellen, die auf lange URLs weiterleiten, benutzerdefinierte Aliase für zahlende Nutzer unterstützen, Klick-Analytics erfassen und Links zulassen, die zu einer festgelegten Zeit ablaufen. Anforderungen: - Verarbeiten Sie 120 Millionen neue Kurzlinks pro Tag. - Verarbeiten Sie 4 Milliarden Redirects pro Tag. - Die Spitzenlast kann das Dreifache des täglichen Durchschnitts erreichen. - Ziel für Redirect-Latenz: p95 unter 80 ms für Nutzer in Nordamerika, Europa und Asien. - Ziel für Kurzlink-Erstellungs-Latenz: p95 unter 300 ms. - Verfügbarkeitsziel des Dienstes: 99,99% für Redirects. - Analytics-Daten können innerhalb von 5 Minuten letztendlich konsistent sein. - Benutzerdefinierte Aliase müssen global eindeutig sein. - Abgelaufene oder gelöschte Links müssen schnell nicht mehr weiterleiten. - Das System sollte regionale Ausfälle tolerieren, ohne dass der Dienst vollständig ausfällt. Annahmen, die Sie verwenden können: - Durchschnittliche Länge einer langen URL beträgt 500 Byte. - Analytics-Ereignisse enthalten Zeitstempel, Link-ID, Land, Gerätetyp und Referrer-Domain. - Leselast ist deutlich höher als Schreiblast. - Sie können bei Bedarf SQL-, NoSQL-, Cache-, Stream-, CDN- und Messaging-Technologien wählen, müssen diese jedoch begründen. Geben Sie in Ihrer Antwort an: 1. Eine Architekturübersicht auf hoher Ebene mit Hauptkomponenten und Anfrageflüssen. 2. Datenmodell und Speicherentscheidungen für Links, Aliase und Analytics. 3. Eine Skalierungsstrategie für leseintensiven Verkehr, einschließlich Caching und regionalem Routing. 4. Eine Zuverlässigkeitsstrategie, die Failover, Konsistenzentscheidungen und den Umgang mit regionalen Ausfällen abdeckt. 5. Wichtige Trade-offs, Engpässe und mindestens drei Risiken mit Gegenmaßnahmen. 6. Eine kurze Kapazitätsschätzung für Speicher und Durchsatz unter Verwendung der obigen Zahlen.
Systemdesign
Entwerfe einen globalen URL-Kürzungsdienst
Entwerfe einen öffentlichen URL-Kürzungsdienst ähnlich wie Bitly. Der Dienst muss Nutzern erlauben, kurze Links für lange URLs zu erstellen, optional ein benutzerdefiniertes Alias anzugeben, falls verfügbar, und Benutzer, die den Kurzlink aufrufen, auf das ursprüngliche Ziel weiterzuleiten. Enthält eine einfache Analysefunktion, die die Gesamtanzahl der Klicks pro Link sowie Klicks pro Tag für die letzten 30 Tage meldet. Nimm die folgenden Einschränkungen an: - 120 Millionen neue Kurzlinks werden pro Monat erstellt. - 1,2 Milliarden Weiterleitungsanfragen werden pro Monat bedient. - Leseverkehr ist stark bursty, insbesondere für virale Links. - Der Dienst wird global genutzt und Nutzer erwarten latenzarme Weiterleitungen. - Kurzlinks sollten mindestens 5 Jahre gültig bleiben. - Ziel für die Verfügbarkeitsrate der Weiterleitung: 99,99 Prozent. - Analytics dürfen bis zu 10 Minuten eventual konsistent sein. - Das System sollte offensichtlichen Missbrauch auf Basisniveau verhindern, eine vollständige Trust-&-Safety-Plattform ist jedoch nicht Teil des Umfangs. Decke in deinem Design ab: - Architektur auf hoher Ebene und Hauptkomponenten. - Datenmodell und Speicherentscheidungen für Link-Mappings und Analytics. - ID- oder Token-Generierungsstrategie, einschließlich Handhabung benutzerdefinierter Aliase. - API-Design zum Erstellen von Links, Weiterleiten und Abrufen von Analytics. - Caching-, Partitionierungs- und Replikationsstrategie. - Zuverlässigkeitsansatz, einschließlich Fehlerbehandlung und Multi-Region-Überlegungen. - Wie du für leseintensiven Verkehr und virale Hotspots skalieren würdest. - Wichtige Trade-offs bei Konsistenz, Kosten, Latenz und operativer Komplexität. Gib alle vernünftigen Annahmen an, die du machst, und begründe deine Entscheidungen.
Systemdesign
Entwerfen Sie eine Echtzeit-Fahrtenvermittlungsplattform
Entwerfen Sie die Backend-Architektur für eine Ride-Hailing-Plattform, die Fahrgäste in Echtzeit mit nahegelegenen Fahrern in mehreren Städten verbindet. Ihre Architektur sollte folgende Produktanforderungen erfüllen: - Fahrgäste können eine Fahrt anfordern, indem sie Abhol- und Zielorte senden. - Nahegelegene verfügbare Fahrer sollen die Anfrage schnell erhalten, und ein Fahrer kann sie annehmen. - Das System muss Doppelbuchungen von Fahrern verhindern. - Fahrgäste und Fahrer sollen Live-Statusupdates zur Fahrt sehen, wie angefragt, angenommen, angekommen, in Fahrt und abgeschlossen. - Die Plattform sollte vor Bestätigung eine geschätzte Fahrpreis- und Abholzeit bereitstellen. - Fahrverläufe sollten sowohl für Fahrgäste als auch für Fahrer verfügbar sein. Einschränkungen und Annahmen: - 8 Millionen Fahrtenanfragen pro Tag. - Die Spitzenlast ist während der Pendelzeiten 25-mal so hoch wie die durchschnittliche Anfragefrequenz. - Betrieb in 40 Städten mit ungleicher Verkehrsverteilung. - Standortupdates aktiver Fahrer kommen alle 3 Sekunden an. - Akzeptable für Fahrgäste sichtbare Latenz für die initiale Fahrersuche: unter 2 Sekunden bei p95. - Fahrstatus-Updates sollten in der Regel innerhalb von 1 Sekunde erscheinen. - Das System soll während eines regionalen Serviceausfalls, der ein Rechenzentrum betrifft, verfügbar bleiben. - Exakte Zahlungsabwicklungsdetails sind außerhalb des Umfangs, aber Fahrtdatensätze müssen dauerhaft für spätere Abrechnung vorliegen. - Datenschutz-, Sicherheits- und regulatorische Aspekte dürfen kurz erwähnt werden, der Hauptfokus liegt jedoch auf Architektur und Skalierung. Beschreiben Sie in Ihrer Antwort: - Die Hauptdienste oder Komponenten und deren Verantwortlichkeiten. - Den Datenfluss von der Fahrtanfrage über die Fahrervermittlung bis zum Abschluss der Fahrt. - Wie Sie Fahrerstandorte effizient speichern und abfragen würden. - Wie Sie für Spitzenverkehr und Hotspot-Städte skalieren würden. - Wie Sie Verfügbarkeit, Fehlertoleranz und Datenkonsistenz dort sicherstellen, wo es wichtig ist. - Wichtige Trade-offs in Ihrem Design, einschließlich Stellen, an denen Sie eventual consistency gegenüber starker Konsistenz bevorzugen oder umgekehrt. Sie müssen keine genauen Cloud-Anbieterprodukte angeben. Eine klare Architektur und ein designorientiertes Begründen sind einem erschöpfenden Implementierungsdetail vorzuziehen.