System Design · Modul 9: Fallstudien

Lektion 1 von 7Übung 18 Min.

Fallstudie: Kurzlink-Dienst

Lernziele
  • eine Entwurfsaufgabe mit einem festen Vorgehen strukturieren
  • aus Überschlagsrechnungen Architekturentscheidungen ableiten
  • ein leselastiges System mit Cache und CDN entwerfen
  • Kurzcodes sicher und kollisionsfrei erzeugen

Mit dieser Lektion beginnt der praktische Abschluss des Kurses. In fünf Fallstudien wenden Sie alles an, was Sie gelernt haben – von Anforderungen und Überschlagsrechnungen über Datenhaltung und Skalierung bis zu Zuverlässigkeit, Sicherheit und KI. Jede Fallstudie folgt demselben Vorgehen, das sich auch in Projekten und Vorstellungsgesprächen bewährt: erst klären, was gebaut werden soll, dann Größenordnungen schätzen, Schnittstellen und Datenmodell festlegen, eine erste Architektur skizzieren, die kritischen Stellen vertiefen und schließlich die Abwägungen offen benennen. Den Anfang macht ein Klassiker: ein Dienst, der lange Adressen in kurze Links verwandelt.

1. Anforderungen2. Überschlag3. API & Daten4. Architektur5. Vertiefung6. Abwägungen

1. Anforderungen

Ein Kurzlink-Dienst wirkt einfach, doch schon die Anforderungen verlangen Entscheidungen. Funktional: Nutzer geben eine lange Adresse ein und erhalten einen kurzen Link. Wer den kurzen Link aufruft, wird weitergeleitet. Optional sind eigene Wunschkürzel, ein Ablaufdatum und eine Klickstatistik. Nicht funktional: Weiterleitungen müssen sehr schnell sein, denn sie verzögern jeden Klick. Der Dienst muss hochverfügbar sein, weil ausgefallene Kurzlinks in gedruckten Flyern oder Newslettern nicht mehr repariert werden können. Kurzcodes dürfen nicht erratbar sein, damit niemand fremde Links durchprobieren kann. Und die Statistik darf ruhig einige Sekunden hinterherhinken.

Klären Sie zu Beginn jeder Entwurfsaufgabe, was gelesen und was geschrieben wird, was schnell und was nur korrekt sein muss – und was bewusst nicht dazugehört. Diese Abgrenzung spart später die meiste Arbeit.

2. Überschlag

1. Anforderungen2. Überschlag3. API & Daten4. Architektur5. Vertiefung6. Abwägungen

Die wichtigste Erkenntnis ergibt sich aus dem Verhältnis von Lesen zu Schreiben: Ein Link wird einmal angelegt, aber oft hundert- oder tausendmal aufgerufen. Das System ist extrem leselastig. Spielen Sie mit den Zahlen:

RechnerÜberschlag für einen Kurzlink-Dienst

1,2/s

Schreiben

116/s

Lesen

3,5 Bio.

mögliche Codes

91 GB

Speicher in 5 Jahren

100.000 neue Links am Tag und 100-mal so viele Aufrufe ergeben rund 116 Weiterleitungen pro Sekunde (Spitze etwa 347). 7 Zeichen aus 62 Symbolen reichen für praktisch unbegrenzt.

Selbst bei hunderttausend neuen Links am Tag ist das Schreiben mit etwas mehr als einem Vorgang pro Sekunde trivial. Das Lesen dagegen erreicht schnell Hunderte oder Tausende Anfragen pro Sekunde. Der Speicherbedarf bleibt überschaubar: Ein Eintrag mit Ziel-URL und Metadaten umfasst etwa 500 Byte, sodass selbst Jahre an Daten auf eine einzige Datenbank passen. Der Entwurf muss sich also vor allem um schnelle, ausfallsichere Weiterleitungen kümmern.

3. API und Datenmodell

1. Anforderungen2. Überschlag3. API & Daten4. Architektur5. Vertiefung6. Abwägungen

Die Schnittstelle ist schlank: POST /links mit Ziel-URL und optionalem Wunschkürzel legt einen Link an und liefert den Kurzcode zurück. GET /:code leitet weiter. GET /links/:code/statistik liefert Klickzahlen für den Besitzer. Das Datenmodell besteht aus einer Tabelle links mit Kurzcode als eindeutigem Schlüssel, Ziel-URL, Besitzer, Erstellungsdatum und optionalem Ablaufdatum sowie einer Tabelle oder einem Ereignisstrom für Klicks. Die entscheidende Frage ist, wie der Kurzcode entsteht. Beurteilen Sie die Varianten:

ÜbungGute oder schlechte Entscheidung?
  1. Kurzcode = fortlaufende Nummer in Base62 (1, 2, 3 … → „b“, „c“, „d“)

  2. Kurzcode = 7 zufällige Zeichen, bei Kollision neu würfeln

  3. Kurzcode = die ersten 7 Zeichen eines Hashes der Ziel-URL

  4. Weiterleitung mit 302 statt 301, damit jeder Klick gezählt wird

0 von 4 eingeschätzt

4. Architektur

1. Anforderungen2. Überschlag3. API & Daten4. Architektur5. Vertiefung6. Abwägungen

Aus Anforderungen und Überschlag ergibt sich eine klare Architektur: Der Lesepfad wird so kurz und schnell wie möglich gemacht, der Schreibpfad bleibt einfach. Klicken Sie sich durch eine Weiterleitung:

Klick-GrafikEine Weiterleitung im Detail
BrowserCDN / EdgeWeiterleitungsdienstCache (Redis)DatenbankKlick-Ereignis
Schritt 1/5 · Aufruf: Jemand öffnet kl.ink/aB3xK9p. Die Anfrage erreicht zuerst den nächstgelegenen CDN-Knoten.

Die Klicks werden von einem Worker gesammelt und stapelweise gezählt, etwa in einer Analysetabelle mit Zählern pro Link und Tag. So belastet die Statistik den Lesepfad nicht. Die Anwendungsserver sind zustandslos und laufen auf mindestens zwei Instanzen, die Datenbank hat ein Replikat mit automatischem Failover.

5. Vertiefung

1. Anforderungen2. Überschlag3. API & Daten4. Architektur5. Vertiefung6. Abwägungen

Drei Stellen verdienen einen genaueren Blick. Missbrauch: Kurzlink-Dienste werden gern für Phishing genutzt, weil der Kurzlink das eigentliche Ziel verbirgt. Neue Ziel-URLs sollten deshalb gegen Listen bekannter Schadseiten geprüft werden, anonyme Nutzung braucht strenge Rate Limits, und eine Vorschauseite hilft Nutzern, das Ziel vor dem Aufruf zu sehen. Beliebte Links: Wird ein Link in einer großen Kampagne geteilt, entstehen Lastspitzen auf einem einzigen Schlüssel. Der Cache fängt das ab; zusätzlich kann das CDN Weiterleitungen für eine kurze Zeit zwischenspeichern. Ablauf und Löschung: Abgelaufene Links werden nicht sofort gelöscht, sondern markiert und von einem Hintergrundjob aufgeräumt; ihre Codes werden nicht wiederverwendet, damit alte Drucksachen nie auf ein fremdes Ziel zeigen.

6. Abwägungen

1. Anforderungen2. Überschlag3. API & Daten4. Architektur5. Vertiefung6. Abwägungen
Tab. 1.1Entscheidungen und ihr Preis
EntscheidungGewinnPreis
302 statt 301jeder Klick wird gezählt, Ziel änderbaretwas mehr Last auf dem Dienst
zufällige Codes statt Nummernnicht erratbarKollisionsprüfung beim Anlegen
Klicks asynchron zählenschnelle WeiterleitungStatistik einige Sekunden verzögert
eine relationale Datenbankeinfach, konsistent, eindeutige Codesbei extremen Größen später Sharding nach Code

Zum Abschluss lohnt der Blick auf die Größenordnung. Für die allermeisten Unternehmen, die einen eigenen Kurzlink-Dienst betreiben wollen – etwa für die Links auf Speisekarten, Flyern oder Rechnungen –, genügen eine kleine Anwendung, eine Postgres-Datenbank und ein CDN. Die Architektur für Millionen Klicks pro Minute ist dieselbe, nur mit mehr Instanzen, einem größeren Cache und gegebenenfalls einer nach Kurzcode aufgeteilten Datenbank. Genau das ist das Ziel eines guten Entwurfs: einfach beginnen, aber so, dass Wachstum keinen Umbau verlangt.

7. Varianten der Aufgabe

Die Aufgabe lässt sich in viele Richtungen erweitern, und in einem Gespräch oder Projekt lohnt es sich, darauf vorbereitet zu sein. Was ändert sich, wenn Unternehmen eigene Domains für ihre Kurzlinks nutzen möchten, etwa go.fahrradladen.de? Dann kommt ein Mandantenmodell hinzu, Zertifikate müssen automatisch ausgestellt werden, und der Kurzcode ist nur noch je Domain eindeutig. Was ändert sich, wenn Links QR-Codes auf Verpackungen bekommen, die jahrzehntelang funktionieren müssen? Dann rückt die Langlebigkeit in den Vordergrund: stabile Domain, sorgfältige Backups, niemals wiederverwendete Codes und ein Plan für den Fall, dass der Dienst eines Tages eingestellt wird. Und was ändert sich, wenn Marketingteams wissen wollen, aus welchem Land und von welchem Gerät Klicks kommen? Dann wächst die Statistik zu einer kleinen Analyseplattform, und der Datenschutz verlangt, IP-Adressen nur gekürzt oder gar nicht zu speichern.

Jede dieser Varianten verändert einen anderen Teil des Entwurfs, aber keine verlangt eine völlig neue Architektur. Das ist ein gutes Zeichen: Ein solider Grundentwurf lässt sich an neue Anforderungen anpassen, statt bei jeder Erweiterung von vorn zu beginnen.

8. So präsentieren Sie den Entwurf

Ob im Vorstellungsgespräch oder vor einem Kunden: Die Art, wie ein Entwurf vorgestellt wird, entscheidet oft mehr als jedes technische Detail. Bewährt hat sich, zuerst die Anforderungen und die wichtigste Zahl zu nennen – hier das Verhältnis von Lesen zu Schreiben –, dann eine einfache Skizze mit fünf oder sechs Kästen zu zeigen und erst danach in die Tiefe zu gehen. Wer mit Details beginnt, verliert sein Publikum. Wer Abwägungen offen benennt, gewinnt Vertrauen: „Wir zählen Klicks verzögert, weil die Weiterleitung schnell sein muss; dafür ist die Statistik einige Sekunden alt.“ Solche Sätze zeigen, dass eine Entscheidung bewusst getroffen wurde und nicht aus Gewohnheit.

Quellen und weiterführende Literatur
  1. [1]Xu, A. (2020): System Design Interview – An Insider's Guide. Kap. 8: Design a URL Shortener.
  2. [2]IETF RFC 9110 (2022): HTTP Semantics – 301 Moved Permanently, 302 Found.
  3. [3]Google (2026): Safe Browsing API Documentation.
  4. [4]Kleppmann, M. (2017): Designing Data-Intensive Applications. Sebastopol: O'Reilly, Kap. 1.

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

Abschlussquiz

Drei Fragen – dann ist die Lektion geschafft.

Frage 1 von 3

Was ist bei einem Kurzlink-Dienst typischerweise viel häufiger?