Entwerfen Sie einen URL-Verkürzungsdienst im großen Maßstab

### A. Architektur auf hoher Ebene Das System ist als eine Menge verteilter, zustandsloser Microservices konzipiert, die über mehrere geografische Regionen hinweg bereitgestellt werden, um hohe Verfügbarkeit und geringe Latenz sicherzustellen. Die Hauptkomponenten sind: 1. **Globaler Load Balancer (GLB)**: Verteilt den Benutzerverkehr mithilfe von DNS-basiertem Routing (z. B. AWS Route 53, Google Cloud Load Balancing) an die nächstgelegene und gesündeste Region. 2. **Regionale Load Balancer (RLB)**: Verteilen den Verkehr innerhalb einer einzelnen Region auf den Pool von Webservern. 3. **API-Gateway / Webserver**: Eine Schicht zustandsloser Server, die TLS terminieren und eingehende HTTP-Anfragen sowohl für Schreibvorgänge (Verkürzung) als auch für Lesevorgänge (Weiterleitung) verarbeiten. 4. **Weiterleitungsdienst (Lesepfad)**: Ein hochgradig optimierter Dienst, der für das Nachschlagen von Kurzcodes und das Ausgeben von HTTP-301/302-Weiterleitungen verantwortlich ist. Er interagiert primär mit der Caching-Schicht. 5. **URL-Verkürzungsdienst (Schreibpfad)**: Ein Dienst, der die Erstellung neuer Kurz-URLs übernimmt. Er koordiniert sich mit dem Schlüsselerzeugungsdienst und der primären Datenbank. 6. **Verteilter Cache**: Ein In-Memory-Cache (z. B. Redis Cluster) in jeder Region, der häufig genutzte URL-Zuordnungen speichert, um die strikte Anforderung an geringe Latenz bei Weiterleitungen zu erfüllen. 7. **Primäre Datenbank**: Eine verteilte NoSQL-Datenbank (z. B. Apache Cassandra, Amazon DynamoDB), die als persistente Single Source of Truth für alle URL-Zuordnungen dient und über alle Regionen hinweg repliziert wird. 8. **Schlüsselerzeugungsdienst (KGS)**: Ein dedizierter, hochverfügbarer Dienst, der Chargen eindeutiger, 7 Zeichen langer Kurzcodes vorgeneriert, um Kollisionen und Latenz zur Schreibzeit zu vermeiden. 9. **Analytics-Pipeline**: Eine asynchrone Datenpipeline, beginnend mit einer Message Queue (z. B. Apache Kafka), um Clickstream-Daten aufzunehmen, ohne die Leistung des Weiterleitungsdienstes zu beeinträchtigen. Diese Daten werden anschließend verarbeitet und in einer separaten Analytics-Datenbank gespeichert. ### B. Strategie zur URL-Generierung **Ansatz**: Wir verwenden einen dedizierten Schlüsselerzeugungsdienst (KGS), um eindeutige Schlüssel vorab zu generieren. **Mechanismus**: 1. Der KGS verwaltet einen Zähler auf verteilte, fehlertolerante Weise (z. B. mit ZooKeeper oder einem atomaren Zähler in einer Datenbank wie Redis). 2. Er erzeugt große, sequenzielle numerische IDs. Um hohe Verfügbarkeit sicherzustellen, können mehrere KGS-Instanzen betrieben werden, wobei jede für einen anderen ID-Bereich verantwortlich ist (z. B. verarbeitet Server 1 die IDs 1 bis 1.000.000, Server 2 die IDs 1.000.001 bis 2.000.000). 3. Jede numerische ID wird dann in eine Base-62-Zeichenkette ([a-z, A-Z, 0-9]) umgewandelt, um den 7 Zeichen langen Kurzcode zu erzeugen. Ein Raum von 62^7 liefert ~3,5 Billionen eindeutige Codes, was mehr als ausreichend ist. 4. Der KGS erzeugt diese Codes in Chargen und legt sie in eine Queue (z. B. eine Redis-Liste), aus der der URL-Verkürzungsdienst sie entnimmt. **Begründung**: Dieser Ansatz vermeidet die Notwendigkeit, während eines Schreibvorgangs in der Hauptdatenbank auf Kollisionen zu prüfen, was langsam wäre und einen Engpass darstellen würde. Er macht den Schreibpfad extrem schnell und vorhersehbar, da der Verkürzungsdienst lediglich einen garantiert eindeutigen Schlüssel vom KGS abrufen muss. ### C. Datenmodell und Speicherung **Primärer Speicher (URL-Zuordnungen)**: * **Technologie**: Apache Cassandra oder Amazon DynamoDB. * **Warum**: Diese NoSQL-Datenbanken bieten ausgezeichnete horizontale Skalierbarkeit, native Multi-Region-Replikation, hohe Verfügbarkeit und latenzarme Schlüssel-Wert-Nachschlagevorgänge, was perfekt zu unseren Anforderungen in Bezug auf Skalierung und Fehlertoleranz passt. * **Schema**: * Tabellenname: `url_mappings` * Partition Key: `short_code` (string) * Spalten: * `long_url` (string) * `user_id` (string, für Eigentümerschaft) * `created_at` (timestamp) **Cache-Speicher**: * **Technologie**: Redis Cluster. * **Warum**: Redis bietet extrem latenzarmen (unter einer Millisekunde) In-Memory-Datenzugriff, was essenziell ist, um die Weiterleitungsanforderung von <10 ms zu erfüllen. Es kann zur Skalierbarkeit und hohen Verfügbarkeit als Cluster betrieben werden. **Analytics-Speicher**: * **Technologie**: Eine spaltenorientierte Datenbank wie Apache Druid, ClickHouse oder ein Cloud-Data-Warehouse wie Google BigQuery. * **Warum**: Diese Systeme sind für schnelle Aggregationen und analytische Abfragen über riesige Datensätze optimiert, was ideal ist, um das Analytics-Dashboard zu betreiben. ### D. Optimierung des Lesepfads Der Lesepfad ist in Bezug auf Latenz stark optimiert und nutzt eine mehrschichtige Caching-Strategie, um die 40.000 Spitzen-QPS zu bewältigen. 1. **CDN/Edge-Cache**: Für extrem populäre URLs kann ein CDN die 301/302-Weiterleitungsantwort an Edge-Standorten zwischenspeichern und Benutzer vom nächstgelegenen Point of Presence bedienen, ohne unsere Kerninfrastruktur zu treffen. 2. **Verteilter In-Memory-Cache (Redis)**: Dies ist die primäre Arbeitseinheit für geringe Latenz. Der Weiterleitungsdienst fragt zuerst den regionalen Redis-Cluster ab. Ein Cache-Treffer führt zu einer sofortigen Weiterleitung. * **Schätzung der Cache-Größe**: Um 20 % von 5 Jahren an URLs zu cachen (100 M/Monat * 12 * 5 * 0,2 = 1,2 B URLs). Bei ~600 Byte pro Eintrag (Kurzcode, lange URL, Overhead) sind dafür ungefähr 720 GB RAM pro Region erforderlich, was für einen Redis-Cluster realisierbar ist. 3. **Datenbankabfrage**: Bei einem Cache-Fehlschlag fragt der Dienst die primäre Cassandra-/DynamoDB-Datenbank ab. Das Ergebnis wird dann mit einer Time-To-Live (TTL) zurück in den Redis-Cache geschrieben, um sicherzustellen, dass der Cache mit häufig abgerufenen Einträgen gefüllt bleibt. Diese Architektur stellt sicher, dass die überwiegende Mehrheit der Anfragen aus dem Speicher bedient wird und damit das p99-Latenzziel von <10 ms problemlos erreicht. ### E. Schreibpfad Der Schreibpfad ist auf Zuverlässigkeit und Durchsatz (~400 Spitzenschreibvorgänge/Sekunde) ausgelegt. 1. Ein Benutzer sendet eine POST-Anfrage mit der langen URL an das API-Gateway. 2. Die Anfrage wird an eine Instanz des URL-Verkürzungsdienstes weitergeleitet. 3. Der Dienst validiert die lange URL. 4. Er fordert einen eindeutigen Kurzcode vom Schlüsselerzeugungsdienst (KGS) an. 5. Der Dienst schreibt die neue Zuordnung (`short_code`, `long_url`) mit einem hohen Konsistenzniveau für die lokale Region in die primäre Datenbank (Cassandra/DynamoDB). 6. Die Datenbank repliziert diesen Schreibvorgang asynchron in andere Regionen. 7. Nach erfolgreichem Schreibvorgang in die Datenbank gibt der Dienst die neue Kurz-URL an den Benutzer zurück. ### F. Skalierungsstrategie Das System ist so entworfen, dass es auf jeder Schicht horizontal skaliert: * **Zustandslose Dienste**: Das API-Gateway, der Weiterleitungsdienst und der Verkürzungsdienst sind zustandslos. Wir können sie skalieren, indem wir weitere virtuelle Maschinen oder Container hinter den Load Balancern hinzufügen. * **Datenbank**: Cassandra und DynamoDB sind für horizontale Skalierung durch Hinzufügen weiterer Knoten zum Cluster ausgelegt. Die Daten und die Last werden automatisch neu ausbalanciert. * **Cache**: Redis Cluster kann durch Hinzufügen weiterer Knoten und erneutes Sharding des Schlüsselraums skaliert werden. * **Analytics-Pipeline**: Kafka skaliert durch das Hinzufügen weiterer Broker und Partitionen. Die Consumer-Dienste, die die Daten verarbeiten, können ebenfalls horizontal skaliert werden. ### G. Zuverlässigkeit und Fehlertoleranz Hohe Verfügbarkeit wird durch Redundanz über mehrere geografische Regionen hinweg erreicht (z. B. US-East, US-West, EU-West). * **Multi-Region-Bereitstellung**: Der gesamte Stack wird in mindestens zwei unabhängigen Regionen bereitgestellt. * **Globales Failover**: Der globale Load Balancer überwacht kontinuierlich den Gesundheitszustand jeder Region. Wenn eine gesamte Region nicht mehr verfügbar ist, leitet der GLB den gesamten Verkehr automatisch an die gesunden Regionen weiter. * **Datenreplikation**: Die primäre Datenbank (Cassandra/DynamoDB) ist für Multi-Region-Replikation konfiguriert. Dies stellt sicher, dass die Daten erhalten bleiben, wenn eine regionale Datenbank ausfällt, da sie in anderen Regionen bewahrt werden. Schreibvorgänge können weiterhin in den verbleibenden aktiven Regionen bedient werden. * **Kein Single Point of Failure**: Jede Komponente, von den Load Balancern bis hin zum KGS und den Datenbanken, wird in einer geclusterten, fehlertoleranten Konfiguration bereitgestellt. ### H. Analytics-Pipeline Die Analytics-Pipeline ist so konzipiert, dass sie vollständig vom kritischen Weiterleitungspfad entkoppelt ist, um jede Leistungseinbuße zu verhindern. 1. **Datenaufnahme**: Nach dem erfolgreichen Ausliefern einer Weiterleitung veröffentlicht der Weiterleitungsdienst eine Nachricht in einem Kafka-Topic. Diese Nachricht enthält Ereignisdaten wie `short_code`, `timestamp`, `IP address`, `User-Agent` und `Referrer`. Dies ist ein asynchroner, nicht blockierender Vorgang. 2. **Datenverarbeitung**: Eine separate Flotte von Stream-Processing-Workern (z. B. mit Spark Streaming, Flink oder benutzerdefinierten Consumern) liest Nachrichten aus dem Kafka-Topic in Chargen. 3. **Datenanreicherung & Aggregation**: Diese Worker reichern die Daten an (z. B. durch Umwandlung der IP in eine Geo-Location) und führen Echtzeit-Aggregationen durch (z. B. Erhöhung der Klickzahlen pro Stunde, pro Land). 4. **Datenspeicherung**: Die verarbeiteten und aggregierten Daten werden in die Analytics-Datenbank (ClickHouse/Druid) geladen, die darauf optimiert ist, die benutzerseitigen Dashboard-Abfragen effizient zu unterstützen. Diese asynchrone Architektur stellt sicher, dass selbst ein massiver Verkehrsspitzenanstieg oder ein Ausfall in der Analytics-Pipeline keinerlei Auswirkungen auf die Geschwindigkeit und Verfügbarkeit von URL-Weiterleitungen hat. ### I. Zentrale Trade-offs 1. **Eventual Consistency vs. Strong Consistency**: Wir haben uns für ein Modell der letztendlichen Konsistenz bei der Datenreplikation über Regionen hinweg entschieden. Eine in einer Region erstellte URL kann einige Millisekunden benötigen, um in einer anderen verfügbar zu sein. Dieser Trade-off verbessert die Schreiblatenz und die Systemverfügbarkeit erheblich, was für diese Anwendung wichtiger ist als sofortige globale Konsistenz. 2. **Kosten vs. Leistung**: Wir verwenden einen großen, teuren In-Memory-Redis-Cache, um die strikte p99-Latenzanforderung von <10 ms zu erfüllen. Eine günstigere, festplattenbasierte Lösung wäre nicht in der Lage, dieses zentrale Performance-SLA zu erfüllen. Wir tauschen höhere Betriebskosten gegen garantierte geringe Latenz auf dem kritischen Lesepfad ein. 3. **Komplexität vs. Skalierbarkeit (KGS)**: Wir haben einen separaten Schlüsselerzeugungsdienst (KGS) eingeführt, anstatt Hashes oder Zufallszeichenketten on the fly zu erzeugen. Das fügt eine zusätzliche Komponente hinzu, die entwickelt und gewartet werden muss, und erhöht damit die Systemkomplexität. Es eliminiert jedoch vollständig Datenbank-Hotspots und die Logik zur Kollisionsprüfung auf dem Schreibpfad, was ein entscheidender Trade-off ist, um bei Skalierung hohen Durchsatz und latenzarme Schreibvorgänge sicherzustellen.

Zusammenfassung Ich schlage einen global verteilten, cache-first URL-Shortener vor mit: einem schlanken Edge-Redirect-Pfad (CDN + Edge-Funktion + lokaler Cache), um die Anforderung einer Redirect-Latenz von <10 ms bei p99 zu erfüllen; einem dauerhaften, Multi-Region-Primärspeicher für kanonische Zuordnungen; einem verteilten ID-Allocator zur Generierung eindeutiger, in Base62 kodierter Kurzcodes (<=7 Zeichen); einer asynchronen Analyse-Pipeline (Kafka/Kinesis → Stream-Prozessoren → OLAP-Speicher), die strikt vom Redirect-Pfad entkoppelt ist; und Multi-Region-Replikation und Failover für die Verfügbarkeit bei einem vollständigen Rechenzentrumsausfall. A. Architektur auf hoher Ebene (Komponenten und Interaktionen) - Edge-Schicht (CDN): Cloud CDN (z. B. Amazon CloudFront, Fastly) schaltet alle GET /{code}-Redirect-Anfragen vor. Die meisten Anfragen werden aus dem CDN-Edge-Cache mit einer zwischengespeicherten 301/302-Antwort bedient. - Edge-Funktion (CloudFront Function / Fastly Compute / Lambda@Edge): Bei Cache-Miss ruft eine winzige Edge-Funktion eine regionale Redirect-API (über einen kurzen RPC/HTTP) auf, um die kanonische Ziel-URL abzurufen und eine 301/302 zurückzugeben. Die Edge-Funktion fügt minimale Logik hinzu, um die richtige Cache-TTL zu wählen und gelöschte/fehlende Codes zu behandeln. - Regionale Redirect-API / Read-Cache-Schicht: zustandslose Leseserver in jeder Region, die zuerst einen regionalen In-Memory-Cache (Redis-Cluster / ElastiCache oder Memcached) konsultieren und bei Bedarf auf den dauerhaften Key-Value-Store zurückgreifen. - Dauerhafter Key-Value-Store (Primärdatenbank): DynamoDB Global Tables oder Cassandra (Multi-Region), die short_code -> long_url und Metadaten als kanonische Quelle der Wahrheit speichern. - ID-Allocationservice (Range Allocator): ein kleiner Dienst, der ID-Blöcke an Write-API-Server zur lokalen Kurzcode-Generierung übergibt (stellt Eindeutigkeit ohne zentrale Sperre pro Schreibvorgang sicher). - Write-API: Dienst, der Erstellungsanfragen bearbeitet, den Kurzcode reserviert/generiert (über ID-Block), in die Primärdatenbank schreibt und eine Invalidierung an Caches und CDN weiterleitet. Schreibvorgänge sind für die Dauerhaftigkeit synchron zur Primärdatenbank. - Cache-Invalidierung & Weiterleitung: Bei Erstellung/Aktualisierung/Löschung aktualisiert die Write-API regionale Caches und invalidiert CDN-Edge-Einträge über die CDN-Invalidierungs-API oder durch Schreiben von Cache-Control-Headern und Verwendung eines Versions-Tokens in der URL, falls erforderlich. - Analyse-Pipeline (asynchron): Redirect-Ereignisse werden asynchron aufgezeichnet (nicht im synchronen Redirect-Pfad). Edge-Logger oder regionale Leseserver pushen leichte Klick-Ereignisse an einen Nachrichtenbus (Kafka / Kinesis). Stream-Verarbeitung (Flink / Spark Streaming) aggregiert und schreibt in einen Analyse-Speicher (ClickHouse / BigQuery) und in voraggregierte Zähler in einem Lese-optimierten Speicher für Dashboards. - Dashboard-API & UI: liest aggregierte Analysen aus OLAP/Aggregat-Speichern und liefert Benutzer-Dashboards. Dashboard-Abfragen treffen niemals den Redirect-Pfad. B. Strategie zur URL-Generierung Ziele: Eindeutigkeit, Kompaktheit (<=7 alphanumerische Zeichen), hoher Durchsatz, geringe Kollision. Gewählter Ansatz: sequentielle numerische IDs, die in verteilten ID-Blöcken zugewiesen werden, Base62-kodiert zur Erzeugung des Kurzcodes. - Warum Base62-sequentielle IDs: Base62 (a–z, A–Z, 0–9) ergibt 62^7 ≈ 3,52 × 10^12 mögliche Codes mit Strings von bis zu 7 Zeichen – weit mehr als der erwartete Bedarf über die Lebensdauer. Sequentielle IDs sind kompakt kodiert und können bei Bedarf leicht in numerische Werte zurückverwandelt werden. Deterministische Zuordnung vermeidet Hashing-Kollisionen. - Implementierung der ID-Zuweisung: Ein zentraler Allocator weist jedem Schreibserver-Cluster monoton steigende ID-Bereiche (z. B. Blöcke von 1 Mio.) zu. Jeder Schreibserver gibt lokale IDs aus seinem Block ohne externe Koordination aus, was Eindeutigkeit und sehr geringe Latenz gewährleistet. Der Allocator selbst ist klein und kann durch einen hochverfügbaren Speicher (RDS oder einen schlanken ZooKeeper/etcd-basierten Zähler) gesichert werden und wird nur zum Nachfüllen von Blöcken verwendet (geringe QPS). - Kodierung: numerische ID -> Base62-String. Wenn die numerische ID < 62^7 ist, ist die Kodierungslänge <=7. Bei 100 Mio. neuen Kürzungen/Monat (1,2 Mrd./Jahr) bietet die Kapazität von 62^7 > 2.900 Jahre Platz. - Behandlung von Kollisionen: keine erwartet, da numerische IDs eindeutig sind. Dennoch verwendet die Write-API eine bedingte Einfügung in die Primärdatenbank (PUT mit Primärschlüssel == short_code) und Wiederholung bei seltenen Primärdatenbank-Konflikten (sollte nicht passieren, wenn der Allocator korrekt ist). Für vom Benutzer angeforderte benutzerdefinierte Aliase wird geprüft und ein Fehler zurückgegeben, wenn sie bereits vergeben sind. - Optionale Deduplizierung: optional kann ein sekundärer Hash-Index (z. B. SHA-256 der long_url) beibehalten werden, um einen vorhandenen Kurzcode zurückzugeben, wenn dieselbe URL zuvor vom selben Benutzer gekürzt wurde; dies ist ein verhaltensabhängiges Verhalten der Anwendung und optional. C. Datenmodell und Speicherung Auswahl des primären Datenspeichers: DynamoDB Global Tables (verwaltet, Multi-Region, Single-Digit-ms Lese-/Schreibvorgänge) oder Apache Cassandra / ScyllaDB (selbstverwaltet, Multi-Region) als kanonische Wahl. Ich empfehle DynamoDB Global Tables für schnellere Operationen und einfachere Multi-Region-Replikation, es sei denn, Sie müssen Cloud-agnostisch sein. Schema der primären Zuordnungstabelle (optimiert für Key-Value): - Tabellenname: URL_Mapping - Primärschlüssel: short_code (string, PK) - Attribute: long_url (text), user_id (string), created_at (timestamp), custom_alias_flag (bool), deleted_flag (bool), metadata (JSON/Sparse map), analytics_enabled (bool), version (int) - Sekundäre Indizes (optional): user_id -> Liste von short_codes (GSI) für die Verwaltungs-UI; long_hash -> short_code (für Deduplizierung, falls gewünscht) Speicherschätzungen: Gehen Sie davon aus, dass jeder Datensatz durchschnittlich 200 Bytes speichert (short_code ~7 Bytes, URL im Durchschnitt 200? Aber wir können komprimieren; konservativ 200–400 Bytes annehmen). Bei 100 Mio. neuen Zeilen/Monat: 100 Mio. * 200 B = 20 GB/Monat. Jährlich ≈ 240 GB. Zehn Jahre ≈ 2,4 TB. DynamoDB/Cassandra können diese Skala problemlos bewältigen. Analyse-Speicher: Rohe Klick-Ereignisse gehen in append-only Systeme (Kafka/Kinesis) und dann in einen Langzeit-Analyse-Speicher (ClickHouse oder BigQuery) für Aggregation und Dashboards. Voraggregierte Zähler (pro short_code pro Zeitfenster) können in ClickHouse gespeichert und heiße Zähler in Redis für Dashboard-Abfragen zwischengespeichert werden. D. Optimierung des Lesepfads (Erreichen von <10 ms p99 Redirects) Ziel ist es, 99 % der Redirects unter 10 ms von der Anforderungsankunft bis zur Ausgabe von 301/302 zu bedienen. Verwendete Techniken: 1) CDN + Edge Cache (primäre Optimierung): Vollständige 301-Antworten an CDN-Edges zwischenspeichern für fast alle Anfragen. Sehr lange TTLs setzen (effektiv nicht ablaufend), da Zuordnungen nicht ablaufen, aber sofortige Invalidierung unterstützen, wenn eine Zuordnung aktualisiert/gelöscht wird. - Bei CDN-Edge-Hit ist die Latenz zum Client typischerweise <10 ms weltweit. 2) Sehr kleine Edge-Funktion für Cache-Miss-Lookup: CloudFront Function oder Fastly's Edge Compute, um den Laufzeit-Overhead zu minimieren (~sub-ms). Bei Cache-Miss ruft die Edge-Funktion eine regionale Redirect-API über eine kurze TCP-Verbindung (Keepalive) auf und gibt 301 an das CDN zurück. 3) Regionaler Lese-Cache (Redis in jeder Region): Der regionale Cache ist ein Memory-First-Speicher für Zuordnungs-Lookups; typischer Redis GET <1 ms. Ziel der Cache-Hit-Rate: >=99 % für heiße Codes. LFU/LRU-Eviction und Größe verwenden, um den Arbeitsdatensatz zu halten. - Beispiel für Cache-Größe: Angenommen, Spitzen-globale RPS = 40.000 Leseanfragen/Sekunde; Arbeitsdatensatz der Top 50 Mio. Codes (heiße Schwanz) – Speichern von short_code->long_url-Paaren (durchschnittlich 200 Bytes). Speicher = 50 Mio. * 200 B ≈ 10 GB. Ein moderater Multi-Shard-Redis-Cluster (z. B. 4–8 Knoten mit je 32 GB) pro Region kann dies bewältigen. 4) Origin-DB-Zugriff nur bei Cache-Miss: DynamoDB Single-Row GetItem ist typischerweise im niedrigen ms-Bereich (1–10 ms), aber wir sind darauf ausgelegt, nicht im kritischen Pfad für p99 zu sein, indem wir stark cachen. 5) Den Edge-Funktion + HTTP-Pfad minimal halten: HTTP/2 oder HTTP/3 zwischen CDN und Origin verwenden, um die Handhabungs-Latenz zu reduzieren und die Wiederverwendung von Verbindungen zu ermöglichen. 6) Lokales Anycast + Geo-Aware Routing: Client zum nächstgelegenen Edge/Region senden, um die RTT niedrig zu halten. Messung und SLA: Test mit synthetischem Traffic und zugewiesenen 99%-Latenzbudgets: CDN-Hit (Ziel <5 ms), Edge-Funktion + Redis <10 ms, Origin-Fallback akzeptabel für niedrige Perzentile, wird aber überwacht und abgestimmt. E. Schreibpfad: Erstellung und Persistenz 1) Client sendet POST /create (oder über UI) an die Write-API (regionsbewusster Endpunkt). Die Write-API-Schicht ist zustandslos und autoskalierbar. 2) Die Write-API holt eine numerische ID aus ihrem lokal zugewiesenen Block (Range Allocator). Wenn der Block erschöpft ist, fordert sie einen neuen Block vom Allocator an. 3) Kodieren der numerischen ID in einen Base62-Kurzcode. 4) Persistenz in der Primärdatenbank mit bedingter Einfügung: PutItem(short_code, long_url, metadata) mit bedingtem Ausdruck, dass short_code nicht existiert (verhindert versehentliches Überschreiben eines benutzerdefinierten Alias). 5) Nach erfolgreichem Schreiben: - Aktualisieren des regionalen Lese-Caches (Write-Through), damit nachfolgende Redirects den Cache treffen. - Senden einer CDN-Cache-Pre-Warm-Anfrage oder Veröffentlichen einer Invalidierung für diesen short_code an das CDN, damit die neue Zuordnung sofort an den Edges zwischengespeichert wird (oder Nutzung der Cache-Control + Versionierung des CDN, um sie wirksam zu machen). 6) Rückgabe des erstellten Kurzcodes an den Benutzer. Dauerhaftigkeit und Konsistenz: Synchrones Schreiben in die Primärdatenbank mit Replikation über Regionen hinweg (DynamoDB Global Tables oder Cassandra mit Multi-DC-Replikation). Bei Verwendung von DynamoDB kann das Konsistenzmodell für Lesevorgänge letztendlich konsistent sein, aber Schreibvorgänge sind dauerhaft und repliziert. Betriebszahlen: Schreib-QPS im Durchschnitt ~40 Schreibvorgänge/Sekunde (100 Mio./Monat ≈ 38,6/s). Spitzenlastspitzen sind möglich; die Schreibpipeline ist leicht horizontal skalierbar. F. Skalierungsstrategie (horizontale Skalierung) - Zustandslose API / Redirect-Server: horizontale Autoskalierung hinter einem globalen Load Balancer (ALB / GCLB). Server zustandslos halten, damit sie leicht skalierbar sind. - ID-Allocator: geringe QPS – Skalierung durch Fehlertoleranz (Aktiv/Passiv + persistenter Zähler oder delegierte Bereichszuweisung). Größere Blöcke zuweisen, um die Last des Allocators zu reduzieren. - Caches: Redis/ElastiCache-Cluster pro Region, sharded (konsistentes Hashing). Shards hinzufügen, um den Speicher-Durchsatz zu erhöhen. - Primärdatenbank: DynamoDB Auto-Scaling oder Cassandra-Cluster, der Knoten hinzufügen und den Durchsatz erhöhen kann. Instanzgrößen und Replikationsfaktor wählen, um die Lese-/Schreibkapazität zu erfüllen. - Nachrichtenbus (Kafka/Kinesis): Klickstrom nach short_code-Hash partitionieren, um die Aufnahme zu skalieren. Genügend Partitionen für Spitzen-Durchsatz bereitstellen (z. B. bei Spitzen-Redirects 38k RPS, die 38k Ereignisse/Sekunde erzeugen, Kafka-Partitionen und Broker für ~50–100k Ereignisse/s mit Replikationsfaktor 3 bereitstellen). - Analyse-Compute: Flink / Spark-Cluster horizontal basierend auf dem Ereignisvolumen skalieren. - CDN skaliert automatisch; CDN-Konfiguration sollte für Anforderungsraten optimiert werden. G. Zuverlässigkeit und Fehlertoleranz Ziele: Überleben eines vollständigen Rechenzentrumsausfalls, keine Datenverluste. - Multi-Region-Bereitstellung: mindestens zwei aktive Regionen (Multi-Aktiv) mit globalem Routing bereitstellen. Globale Lastverteilung + Health Checks verwenden, um fehlgeschlagene Regionen zu umgehen. - Primärdatenbank-Replikation: DynamoDB Global Tables bieten aktive-aktive Replikation über Regionen hinweg; Cassandra/Scylla kann mit einem Replikationsfaktor über Rechenzentren hinweg konfiguriert werden. Dies bietet Dauerhaftigkeit, wenn ein DC verloren geht. - Regionale Caches sind im Fehlerfall warm: Wenn eine Region ausfällt, wird der Verkehr zur nächsten Region geleitet, die ihren eigenen Cache hat. Kaltstart einer Region nach Failover kann mehr Origin-Lesevorgänge verursachen, bis die Caches aufgewärmt sind, aber die Verfügbarkeit bleibt erhalten. - ID-Allocator-Fehlertoleranz: Allocator-Zustand in einem hochverfügbaren Speicher persistiert; große Blöcke zuweisen, um den Zugriff auf den Allocator bei Failover zu reduzieren. - Nachrichtenbus-Replikation: Kafka mit Replikationsfaktor >=3 über Racks/Regionen oder verwaltetes Kinesis mit Cross-Region-Replikation für Dauerhaftigkeit. - Health Checks und automatisiertes Failover: aktive Überwachung, Circuit Breaker, Ratenbegrenzung, um Überlastung während des Failovers zu verhindern. - Backups: periodische Snapshots der Primärdatenbank und Exporte von Metadaten. Für DynamoDB Point-in-Time Recovery aktivieren; für Cassandra geplante Snapshots. H. Analyse-Pipeline (sammeln/verarbeiten/liefern ohne Beeinträchtigung von Redirects) Designprinzip: Analyse-Schreibvorgänge müssen asynchron erfolgen und dürfen Redirects niemals blockieren. 1) Leichte Ereigniserzeugung: Edge (CDN/Edge-Funktion) gibt ein kleines Ereignis für jeden Redirect aus (short_code, Zeitstempel, Client-IP oder Geo-Tag, Referrer, User-Agent). Um die Redirect-Latenz zu minimieren, erfolgt die Ausgabe über einen sehr schnellen UDP-ähnlichen Push an einen lokalen Proxy oder durch Batching im Speicher des Leseservens und asynchrone Übertragung. 2) Nachrichtenbus: Ereignisse werden an Kafka- oder Kinesis-Topics gepusht, partitioniert nach short_code (oder Hash), um skalierbare parallele Verarbeitung zu unterstützen. Der Produzent muss asynchron und nicht blockierend sein; wenn der lokale Kafka-Puffer voll ist, wird auf Sampling zurückgegriffen oder niedrigwertige Felder fallen gelassen, um sicherzustellen, dass die Redirect-Latenz nicht beeinträchtigt wird. Produzenten verwenden lokale Pufferung und Backpressure-Richtlinien. 3) Stream-Verarbeitung: Flink / Kafka Streams / Spark Streaming verbraucht Ereignisse, reichert sie an (Geo-IP-Lookup, UA-Parsing) und berechnet Echtzeit-Aggregationen (Klickzahlen, Geo-Verteilung, Referrer) in Minuten-/Stunden-Granularität. Voraggregieren pro short_code pro Zeitfenster. 4) OLAP-Speicher & Aggregate: aggregierte Daten in ClickHouse oder BigQuery schreiben für schnelle analytische Abfragen und Langzeitspeicherung. Für die Bereitstellung von Dashboards werden aktuelle Aggregate in einem schnellen Lesespeicher (Redis oder Druid) für interaktive Abfragen gespeichert. 5) Dashboard-API: liest nur aus Aggregat-/OLAP-Speicher; keine direkte Abfrage vom Analyse-Speicher zum Redirect-Pfad. Ratenbegrenzungen und Pro-Benutzer-Kontingente für Dashboard-Abfragen implementieren. 6) Sampling und gestaffelte Protokollierung: für extrem stark frequentierte Kurzcodes optional Ereignisse sampeln, um die Pipeline-Last zu reduzieren und gleichzeitig repräsentative Analysen zu erhalten. Leistungsbeispiel: Spitzen-Redirects ~40k/s -> Ereignisse 40k/s -> Kafka-Aufnahme mit 100 Partitionen und wenigen Brokern leicht zu bewältigen. Stream-Prozessoren skalieren horizontal, um dieses Volumen zu bewältigen und minütlich zusammengefasste Aggregate an ClickHouse zu schreiben. I. Wichtige Kompromisse (mindestens drei) mit Begründung 1) CDN-Edge-Caching vs. sofortige Konsistenz bei Löschungen/Aktualisierungen - Kompromiss: Die Verwendung eines langlebigen CDN-Edge-Caches ergibt eine sehr geringe Redirect-Latenz, macht aber die Weiterleitung von Aktualisierungen/Löschungen etwas komplexer und nicht überall sofort wirksam. - Begründung: Die SLA für die Redirect-Latenz ist streng (<10 ms p99). Typische Operationen zum Ändern/Löschen einer Kurz-URL sind im Vergleich zu Redirects selten. Wir bevorzugen extrem niedrige Latenz für Redirects und akzeptieren eine leicht verzögerte Cache-Invalidierung (wir stellen sofortige Invalidierungs-APIs für wichtige Fälle bereit). Wir beinhalten auch einen Versions-Token oder eine Short-TTL-Invalidierungsstrategie für kritische Aktualisierungen. 2) Sequentielle ID-Zuweisung (Range-Blöcke + Base62) vs. vollständig zufälliges/Hashing-Schema - Kompromiss: Die sequentielle Zuweisung mit Blöcken erfordert einen kleinen Allocator-Dienst und sorgfältige Handhabung bei Cross-Region-Failover, während Hashing/zufällige Generierung vollständig zustandslos sein kann, aber eine Kollisionsauflösung oder eine größere Codierlänge zur Reduzierung von Kollisionen erfordert. - Begründung: Sequentielle IDs erzeugen deterministisch kompakte, sehr kurze Codes und vermeiden die Kollisionsbehandlung zur Schreibzeit. Mit Blockzuweisung ist die Allocator-Last minimal und skalierbar. Angesichts des extrem großen Schlüsselraums (62^7) benötigen wir keine Zufälligkeit, um Kollisionen zu vermeiden. 3) DynamoDB (verwaltet, Multi-Region) vs. selbstgehostetes Cassandra - Kompromiss: DynamoDB vereinfacht den Betriebsaufwand und bietet verwaltete Multi-Region-Replikation, kann aber teurer und etwas weniger flexibel bei Abfragemustern sein als selbstgehostetes Cassandra/Scylla. - Begründung: Das Zugriffsmuster des Systems sind einfache Primärschlüssel-Lese-/Schreibvorgänge; wir legen Wert auf betriebliche Einfachheit, Zuverlässigkeit und automatische Skalierung und empfehlen daher DynamoDB Global Tables, es sei denn, Kostenbeschränkungen zwingen zu Cassandra. 4) Synchroner Write-Through-Cache vs. eventuale Weiterleitung an Caches - Kompromiss: Synchrones Write-Through an Caches erhöht die Schreiblatenz geringfügig, stellt aber die sofortige Verfügbarkeit in Lese-Caches sicher; die eventuale Weiterleitung senkt die Schreiblatenz, kann aber ein kurzes Zeitfenster verursachen, in dem Redirects fehlschlagen. - Begründung: Schreibvorgänge haben eine geringe QPS (≈40/s), daher ist das Schreiben in den Cache bei der Erstellung akzeptabel, um sicherzustellen, dass neu erstellte Links sofort für Redirects verfügbar sind und Cold-Cache-Misses für neu erstellte Kurzcodes vermieden werden. Betriebliche Überlegungen und Telemetrie - Überwachung: p99 Redirect-Latenz, Cache-Hit-Rate, Origin-RPS, Schreiblatenz, Nachrichtenbus-Verzögerung, Analyse-Pipeline-Verzögerung. Alarmierung bei Cross-DC-Replikationsverzögerung. - Kapazitätsplanung: Planung für 10-fachen Spitzenwert als Sicherheit. Beispielzahlen: - Lese-QPS (durchschnittlich): 3.858 RPS = 10 Mrd./Monat. Spitzenannahme 10x => ~38,6k RPS. - CDN-Edge-Hit-Ziel: 99 % → Origin-RPS ≈ 386 RPS. Regionale Caches sind so dimensioniert, dass sie den heißen Arbeitsdatensatz halten. - Cache-Größe: Top 50 Mio. Schlüssel bei 200 B pro Stück → 10 GB; mehrere Shards pro Region verwenden. - Kafka-Durchsatz: bei Spitzenlast 40k Ereignisse/s, mit durchschnittlicher Ereignisgröße 500 B => ~20 MB/s Aufnahme; mit Replikationsfaktor 3 und Overhead für ~60 MB/s Cluster-Durchsatz planen. - Primärdatenbank-Durchsatz: Schreibvorgänge ~40/s, Lesevorgänge vom Origin nach Cache-Misses ~386/s aggregiert (oder pro Region aufgeteilt). DynamoDB-Kapazitäts-Auto-Scaling unterstützt diese Stufen problemlos. Sicherheits- und Betriebsfunktionen - Ratenbegrenzung und Missbrauchserkennung am Edge zur Abwehr von Spam oder Bots. - Drosselung von Analyse-Schreibvorgängen bei Überlastung, Sampling für extrem heiße Codes. - Zugriffskontrollen (OAuth/API-Tokens) zum Erstellen und Verwalten von Kurz-URLs. - Audit-Protokolle für Löschungen, um die Garantie der Nicht-Ablaufzeit zu erfüllen, es sei denn, sie werden explizit gelöscht. Schlussfolgerung Dieses Design priorisiert die Redirect-Latenz und Verfügbarkeit durch CDN-Edge-Caching + minimale Edge-Logik, dauerhafte Multi-Region-Speicherung für permanente Zuordnungen, ein einfaches und robustes ID-Zuweisungs- und Base62-Kodierungsschema (garantiert keine Kollisionen und <=7 Zeichen) und eine vollständig asynchrone Analyse-Pipeline, damit Analysen niemals die Redirect-Leistung beeinträchtigen. Die Architektur skaliert horizontal, überlebt vollständige DC-Ausfälle durch Multi-Region-Replikation und bietet betriebliche Stellhebel (Cache-Größe, CDN-Invalidierung, Sampling), um Kosten gegen Leistung abzuwägen.