- 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. 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.
2. Überschlag
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:
1,2/s
Schreiben
116/s
Lesen
3,5 Bio.
mögliche Codes
91 GB
Speicher in 5 Jahren
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
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:
Kurzcode = fortlaufende Nummer in Base62 (1, 2, 3 … → „b“, „c“, „d“)
Kurzcode = 7 zufällige Zeichen, bei Kollision neu würfeln
Kurzcode = die ersten 7 Zeichen eines Hashes der Ziel-URL
Weiterleitung mit 302 statt 301, damit jeder Klick gezählt wird
4. Architektur
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:
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
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
| Entscheidung | Gewinn | Preis |
|---|---|---|
| 302 statt 301 | jeder Klick wird gezählt, Ziel änderbar | etwas mehr Last auf dem Dienst |
| zufällige Codes statt Nummern | nicht erratbar | Kollisionsprüfung beim Anlegen |
| Klicks asynchron zählen | schnelle Weiterleitung | Statistik einige Sekunden verzögert |
| eine relationale Datenbank | einfach, konsistent, eindeutige Codes | bei 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.
- [1]Xu, A. (2020): System Design Interview – An Insider's Guide. Kap. 8: Design a URL Shortener.
- [2]IETF RFC 9110 (2022): HTTP Semantics – 301 Moved Permanently, 302 Found.
- [3]Google (2026): Safe Browsing API Documentation.
- [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.