Entwerfe einen globalen URL-Kürzungsdienst

Entwurf: Globaler URL-Shortener-Dienst 1. ANFORDERUNGEN UND GROBSCHÄTZUNGEN Funktionale Anforderungen: - Erstellen eines kurzen Links für eine gegebene lange URL (mit optionalem benutzerdefiniertem Alias). - Weiterleiten von Besuchern des kurzen Links zur ursprünglichen URL (HTTP 301/302). - Grundlegende Analysen: Gesamtklicks pro Link, Klicks pro Tag für die letzten 30 Tage. Nicht-funktionale Anforderungen: - 120 Mio. neue Links pro Monat, durchschnittlich etwa 46 Schreibvorgänge pro Sekunde, Spitzenwerte um 200 pro Sekunde. - 1,2 Mrd. Weiterleitungen pro Monat, durchschnittlich etwa 463 pro Sekunde, Spitzenwerte um 5.000–50.000 pro Sekunde für virale Links. - 99,99 % Verfügbarkeit der Weiterleitung. - Globale Weiterleitungen mit geringer Latenz. - Links mindestens 5 Jahre gültig. - Analysen schließlich konsistent innerhalb von 10 Minuten. - Grundlegende Missbrauchsprävention. Speicherplatzschätzung: - 120 Mio. Links pro Monat mal 60 Monate (5 Jahre) ergibt 7,2 Milliarden Links. - Jeder Linkdatensatz mit etwa 500 Bytes (kurzer Code, lange URL, Metadaten) ergibt über 5 Jahre etwa 3,6 TB Linkdaten. - Analysedaten sind zusätzlich, aber mit Aggregation handhabbar. 2. HOCH-EBENEN-ARCHITEKTUR Das System besteht aus den folgenden Hauptkomponenten: a) API-Gateway und Load Balancer: Eingangspunkt für den gesamten Datenverkehr. Behandelt TLS-Terminierung, Ratenbegrenzung, Authentifizierung für die Linkerstellung und Routing. Bereitgestellt in mehreren Regionen hinter einem globalen Anycast-DNS oder einem globalen Load Balancer (z. B. AWS Global Accelerator oder Cloudflare). b) Link-Erstellungsdienst: Zustandsloser Dienst, der POST-Anfragen zur Erstellung neuer kurzer Links bearbeitet. Validiert Eingaben, generiert oder reserviert kurze Codes, prüft die Verfügbarkeit benutzerdefinierter Aliase, wendet grundlegende Missbrauchsprüfungen an und schreibt in die primäre Datenbank. c) Weiterleitungsdienst: Zustandsloser, Lese-optimierter Dienst, der GET-Anfragen für kurze Codes bearbeitet. Sucht den kurzen Code zuerst im Cache, dann in der Datenbank und gibt eine HTTP 301- oder 302-Weiterleitung zurück. Gibt auch asynchron ein Klickereignis für Analysen aus. d) Analysedienst: Verbraucht Klickereignisse aus einer Nachrichtenwarteschlange, aggregiert sie und speichert tägliche und Gesamtklicks. Bedient Analyseabfragen. e) Cache-Schicht: Verteilter Cache (Redis- oder Memcached-Cluster) in jeder Region, um heiße kurze Codes mit Latenzen unter einer Millisekunde zu bedienen. f) Primärdatenbank: Speichert die kanonischen Link-Zuordnungen. Eine verteilte Datenbank wie Amazon DynamoDB, Google Cloud Spanner oder CockroachDB. g) Nachrichtenwarteschlange: Kafka oder Amazon Kinesis zum Puffern von Klickereignissen zwischen dem Weiterleitungsdienst und der Analyse-Pipeline. h) CDN / Edge-Schicht: Für die beliebtesten Links können Weiterleitungsantworten am CDN-Edge zwischengespeichert werden (mit 301 mit entsprechenden Cache-Headern oder Edge-Workern, die die Suche durchführen). Architekturfluss: - Linkerstellung: Client -> API-Gateway -> Link-Erstellungsdienst -> Primärdatenbank (Schreiben) -> Cache invalidieren/füllen -> Kurze URL zurückgeben. - Weiterleitung: Client -> CDN/Edge -> (Cache-Fehlversuch) -> API-Gateway -> Weiterleitungsdienst -> Cache -> (Cache-Fehlversuch) -> DB -> 302-Weiterleitung zurückgeben. Klickereignis asynchron an Nachrichtenwarteschlange senden. - Analyseabfrage: Client -> API-Gateway -> Analysedienst -> Analysedatenbank -> Ergebnisse zurückgeben. 3. DATENMODELL UND SPEICHERUNG Link-Zuordnungstabelle (Primärspeicher – DynamoDB oder ähnlich): - short_code (Partitionsschlüssel): Zeichenkette, 7 Zeichen, z. B. „aB3x9Kz“ - long_url: Zeichenkette, die ursprüngliche URL, bis zu 2048 Zeichen - user_id: Zeichenkette, optional, der Ersteller - custom_alias: boolesch, ob dies ein benutzerdefinierter Alias war - created_at: Zeitstempel - expires_at: Zeitstempel (standardmäßig created_at + 5 Jahre) - click_count: Ganzzahl (schließlich konsistenter Zähler, periodisch aktualisiert) - status: Enum (aktiv, deaktiviert, abgelaufen) Warum DynamoDB: Das Muster der Einzel-Schlüssel-Wert-Suche passt perfekt. Es skaliert horizontal mit konsistenter Latenz im einstelligen Millisekundenbereich. Der Partitionsschlüssel ist der short_code, der aufgrund der zufälligen Natur der generierten Codes gut verteilt ist. Analysespeicher: - Option A: Eine Zeitreihentabelle in DynamoDB oder Cassandra mit Partitionsschlüssel = short_code und Sortierschlüssel = Datum (JJJJ-MM-TT) mit einem click_count-Attribut. - Option B: Vorkompilierte tägliche Zählungen, die in einer separaten Tabelle gespeichert sind, mit einem TTL von 30 Tagen für die Zeilen mit täglicher Granularität. Schema für die tägliche Analysetabelle: - short_code (Partitionsschlüssel): Zeichenkette - date (Sortierschlüssel): Zeichenkette, Format JJJJ-MM-TT - click_count: Ganzzahl - TTL: Zeitstempel, 30 Tage ab Datum Dies ermöglicht effiziente Bereichsabfragen: Alle täglichen Klicks für einen short_code in den letzten 30 Tagen abrufen. Für die Gesamtklickzahlen pflegen wir einen laufenden Zähler in der Haupt-Link-Zuordnungstabelle, der von der Analyse-Pipeline aktualisiert wird. 4. ID/TOKEN-GENERIERUNGSSTRATEGIE Anforderungen: 7,2 Milliarden eindeutige Codes über 5 Jahre. Bei Verwendung der Base62-Kodierung (a-z, A-Z, 0-9) ergibt ein 7-stelliger Code 62^7 = 3,5 Billionen mögliche Kombinationen, was mehr als ausreichend ist. Ansatz: Vorgefertigte ID-Bereiche mittels eines verteilten Zählers oder einer bereichsbasierten Zuweisung. Hauptstrategie: - Verwenden Sie einen zentralen ID-Generierungsdienst (wie Twitter Snowflake oder einen einfacheren Zählerdienst), der Blöcke von numerischen IDs an jede Link-Erstellungsdienstinstanz zuweist. Zum Beispiel fordert jede Instanz einen Block von 10.000 IDs auf einmal an. - Jede numerische ID wird dann in Base62 kodiert, um den 7-stelligen kurzen Code zu erzeugen. - Dies vermeidet Koordination bei jedem Schreibvorgang und gewährleistet gleichzeitig globale Einzigartigkeit. Alternative Überlegung: Zufällige Generierung mit Kollisionsprüfung. Dies funktioniert, erfordert jedoch eine Lese-vor-Schreib-Operation zur Überprüfung auf Kollisionen, was die Latenz erhöht. Bei 7,2 Milliarden Codes von 3,5 Billionen möglichen ist die Kollisionswahrscheinlichkeit gering (etwa 0,2 %), aber die Prüfung ist dennoch erforderlich. Der bereichsbasierte Ansatz ist deterministischer. Handhabung benutzerdefinierter Aliase: - Wenn ein Benutzer einen benutzerdefinierten Alias anfordert, führt der Dienst einen bedingten Schreibvorgang durch (PutItem mit der Bedingung, dass der short_code noch nicht existiert) in die Datenbank. - Wenn die Bedingung fehlschlägt, ist der Alias vergeben und wir geben dem Benutzer einen Fehler zurück. - Benutzerdefinierte Aliase werden validiert: mindestens 4 Zeichen, maximal 30 Zeichen, alphanumerisch plus Bindestriche, Überprüfung gegen eine Blockliste reservierter Wörter und anstößiger Begriffe. - Benutzerdefinierte Aliase werden in derselben Tabelle wie generierte Codes gespeichert, wobei das Flag custom_alias auf true gesetzt ist. 5. API-DESIGN Alle APIs sind RESTful über HTTPS. a) Kurzen Link erstellen: POST /api/v1/links Header: Authorization: Bearer <token> (optional für anonym, erforderlich für Analysezugriff) Anforderungsrumpf: long_url: erforderlich, die Ziel-URL (validiert auf Format und grundlegende Sicherheit) custom_alias: optional, gewünschter kurzer Code expires_in_days: optional, Standard 1825 (5 Jahre) Antwort (201 Created): short_code: „aB3x9Kz“ short_url: „https://sho.rt/aB3x9Kz“ long_url: „https://example.com/very/long/path“ created_at: „2025-01-15T10:30:00Z“ expires_at: „2030-01-15T10:30:00Z“ Fehlerantworten: 400 (ungültige URL), 409 (benutzerdefinierter Alias vergeben), 429 (Ratenbegrenzung) b) Weiterleiten: GET /{short_code} Antwort: 302 Found mit Location-Header auf die lange URL gesetzt. Wir verwenden 302 (temporäre Weiterleitung) anstelle von 301 (permanente Weiterleitung), damit Browser die Weiterleitung nicht dauerhaft cachen, was uns die Verfolgung von Klicks und die mögliche Aktualisierung des Ziels ermöglicht. Aus Performancegründen können wir jedoch 301 am CDN-Edge mit einer kontrollierten TTL verwenden. Fehlerantworten: 404 (nicht gefunden oder abgelaufen), 410 (deaktiviert) c) Analysen abrufen: GET /api/v1/links/{short_code}/analytics Header: Authorization: Bearer <token> Antwort (200 OK): short_code: „aB3x9Kz“ total_clicks: 154302 daily_clicks: Liste von Objekten mit Datum und Anzahl für die letzten 30 Tage Fehlerantworten: 401 (nicht autorisiert), 404 (Link nicht gefunden) d) Link löschen / deaktivieren: DELETE /api/v1/links/{short_code} Header: Authorization: Bearer <token> Antwort: 204 No Content 6. CACHING-, PARTITIONIERUNGS- UND REPLIKATIONSSTRATEGIE Caching: - Schicht 1 – CDN-Edge-Cache: Für den Weiterleitungspfad können wir 302-Antworten am CDN-Edge mit einer kurzen TTL (z. B. 5 Minuten) cachen. Dies bewältigt virale Links extrem gut, da das CDN den Großteil des Datenverkehrs aufnimmt. Wir verwenden Cache-Control-Header mit einem kurzen max-age. Edge-Worker (Cloudflare Workers, Lambda@Edge) können die Suche auch direkt aus einem regionalen KV-Speicher durchführen. - Schicht 2 – Regionaler Redis-Cluster: Jede Region verfügt über einen Redis-Cluster, der short_code-zu-long_url-Zuordnungen zwischenspeichert. Cache-TTL von 24 Stunden. LRU-Eviction-Richtlinie. Dies bewältigt die überwiegende Mehrheit der Weiterleitungsabfragen, ohne die Datenbank zu belasten. - Schicht 3 – Lokaler Anwendungs-Cache: Jede Weiterleitungsdienstinstanz unterhält einen kleinen In-Prozess-LRU-Cache (z. B. 100.000 Einträge) für die heißesten Links. Cache-Größe: Bei 1,2 Mrd. Weiterleitungen pro Monat und einer Zipfschen Verteilung machen die Top 20 % der Links wahrscheinlich 80 % des Traffics aus. Das Caching der Top 10 Mio. aktiven Links in Redis erfordert etwa 10 Mio. mal 300 Bytes = 3 GB pro Region, was sehr überschaubar ist. Cache-Invalidierung: Bei Link-Löschung oder -Aktualisierung veröffentlichen wir ein Invalidierungsereignis über die Nachrichtenwarteschlange an alle Regionen. Cache-Einträge haben auch TTLs als Sicherheitsnetz. Partitionierung: - DynamoDB partitioniert automatisch nach dem short_code-Hash-Schlüssel. Die zufällige Natur der generierten Codes sorgt für eine gleichmäßige Verteilung. - Bei benutzerdefinierten Aliassen ist die Verteilung weniger vorhersehbar, aber die adaptive Kapazität von DynamoDB bewältigt Hotspots. - Redis wird mittels konsistentem Hashing über Cluster-Knoten hinweg partitioniert. Replikation: - DynamoDB Global Tables bieten Multi-Region-Replikation mit letztendlicher Konsistenz (typischerweise unter einer Sekunde). Wir bezeichnen eine Region als primär für Schreibvorgänge (Linkerstellung) und alle Regionen können Lesezugriffe bedienen. - Alternativ bieten CockroachDB oder Spanner stark konsistente Multi-Region-Lesevorgänge, jedoch mit höheren Latenzkosten für Schreibvorgänge. - Redis-Cluster werden innerhalb jeder Region repliziert (Master-Replika). Regionenübergreifende Caches werden unabhängig durch Datenbankreplikation und lokales Aufwärmen des Caches gefüllt. 7. ZUVERLÄSSIGKEITSANSATZ Verfügbarkeitsziel: 99,99 % für Weiterleitungen bedeutet maximal 4,3 Minuten Ausfallzeit pro Monat. Multi-Region-Bereitstellung: - Stellen Sie den Weiterleitungsdienst in mindestens 3 geografisch verteilten Regionen bereit (z. B. US-Ost, EU-West, AP-Südost). - Verwenden Sie globales DNS-basiertes Routing (Route 53 Latenz-basiertes Routing oder Anycast), um Benutzer zur nächstgelegenen Region zu leiten. - Jede Region ist unabhängig in der Lage, Weiterleitungen aus ihrem lokalen Cache und ihrer Datenbankreplika zu bedienen. Fehlerbehandlung: - Wenn die primäre Datenbankregion ausfällt, wird eine andere Region befördert. Mit DynamoDB Global Tables kann jede Region Schreibvorgänge akzeptieren, sodass kein einzelner Schreib-Leader ausfällt. - Wenn Redis in einer Region ausfällt, greift der Weiterleitungsdienst auf die Datenbank zurück. Die Datenbank kann die Last vorübergehend bewältigen und Redis erholt sich schnell. - Wenn die Analyse-Pipeline (Kafka) Probleme hat, werden Klickereignisse gepuffert. Die Haltbarkeit von Kafka stellt sicher, dass keine Daten verloren gehen. Die letztendliche Konsistenz der Analysen innerhalb von 10 Minuten gibt uns Spielraum. - Circuit Breaker werden zwischen Diensten implementiert. Wenn die Datenbank langsam ist, bedient der Weiterleitungsdienst aus dem Cache und degradiert sich anmutig (gibt zwischengespeicherte Ergebnisse oder eine temporäre Fehlermeldung für Cache-Fehlversuche zurück). Integritätsprüfungen und Überwachung: - Jede Dienstinstanz verfügt über Integritätsprüfungs-Endpunkte. - Load Balancer entfernen automatisch fehlerhafte Instanzen. - Umfassende Überwachung mit Dashboards für Latenz-Perzentile (p50, p95, p99), Fehlerraten, Cache-Trefferraten und Warteschlangennachlauf. - Alarmierung bei SLO-Verletzungen. Datensicherheit: - DynamoDB bietet 99,999999999 % Datensicherheit mit regionenübergreifender Replikation. - Regelmäßige Backups als zusätzliche Sicherheitsmaßnahme. 8. SKALIERUNG FÜR LESEHOMOGENEN DATENVERKEHR UND VIRALE HOTSPOTS Das Verhältnis von Lese- zu Schreibzugriffen beträgt ungefähr 10:1 (1,2 Mrd. Lesevorgänge gegenüber 120 Mio. Schreibvorgängen pro Monat), aber während viraler Ereignisse kann ein einzelner Link Millionen von Zugriffen pro Stunde erhalten. Strategien: - CDN-Edge-Caching ist die erste und wirksamste Abwehrmaßnahme. Die Weiterleitungsantwort eines viralen Links wird an Hunderten von Edge-Standorten weltweit zwischengespeichert. Selbst eine TTL von 5 Minuten bedeutet, dass der Ursprung nur einen Request pro 5 Minuten pro Edge-Standort sieht. - Edge-Computing (Cloudflare Workers oder Lambda@Edge) kann die Weiterleitungsabfrage vollständig am Edge durchführen, indem es aus einem verteilten KV-Speicher (wie Cloudflare KV oder DynamoDB DAX) liest, wodurch die Notwendigkeit entfällt, den Ursprung überhaupt zu kontaktieren. - Redis-Cluster-Autoskalierung: Überwachen Sie die Cache-Last und fügen Sie dynamisch Lesereplikate hinzu. - Weiterleitungsdienst-Autoskalierung: Zustandlose Dienste skalieren horizontal basierend auf CPU- und Anforderungsanzahl-Metriken. - Bei extremen Hotspots stellt der lokale Anwendungs-Cache auf jeder Weiterleitungsdienstinstanz sicher, dass selbst wenn Redis unter Druck steht, die heißesten Links aus dem Speicher bedient werden. Analysen während viraler Ereignisse: - Klickereignisse werden an Kafka gesendet, das burstige Schreibvorgänge gut bewältigt. - Der Analyse-Konsument kann vor dem Schreiben in den Analysenspeicher batchen und aggregieren, wodurch die Schreibverstärkung reduziert wird. - Wir verwenden bei Bedarf ungefähre Zählungen (HyperLogLog für eindeutige Besucher), aber für Gesamtklicks reichen einfache Zähler aus. 9. MISSBRAUCHSPRÄVENTION Grundlegende Maßnahmen (vollständige Vertrauens- und Sicherheitsprüfung ist nicht Teil des Umfangs): - Ratenbegrenzung bei der Linkerstellung: pro IP und pro authentifiziertem Benutzer (z. B. 100 Links pro Stunde für anonyme Benutzer, 1000 für authentifizierte). - URL-Validierung: Ablehnen von fehlerhaften URLs, Überprüfung gegen bekannte Phishing-/Malware-URL-Blocklisten (z. B. Google Safe Browsing API). - Validierung benutzerdefinierter Aliase: Blockliste von anstößigen und reservierten Wörtern. - CAPTCHA für anonyme Linkerstellung, wenn Ratenbegrenzungen erreicht werden. - Möglichkeit, als missbräuchlich gemeldete Links zu deaktivieren (manuell oder automatisiert). - Protokollierung und Audit-Trail für alle Linkerstellungsereignisse. 10. WICHTIGE KOMPROMISSE Konsistenz vs. Latenz: - Wir entscheiden uns für letztendliche Konsistenz für die Link-Zuordnung über Regionen hinweg. Ein neu erstellter Link ist möglicherweise für einige hundert Millisekunden in einer entfernten Region nicht auflösbar. Dies ist akzeptabel, da der Benutzer, der den Link erstellt, zur nächstgelegenen Region geleitet wird, in der der Schreibvorgang sofort konsistent ist, und die regionenübergreifende Replikation schnell erfolgt. Für Analysen akzeptieren wir explizit eine letztendliche Konsistenz von 10 Minuten. 302 vs. 301 Weiterleitungen: - 302 (temporär) ermöglicht uns, jeden Klick zu verfolgen und Ziele zu ändern, erhöht aber die Ursprungslast. 301 (permanent) ist effizienter, wird aber von Browsern unbegrenzt zwischengespeichert. Unser Kompromiss: 302 vom Ursprung verwenden, aber CDN-Edge-Caching mit kurzer TTL zulassen, was uns das Beste aus beiden Welten bietet. Kosten vs. Leistung: - DynamoDB On-Demand-Preise sind pro Anfrage teurer als bereitgestellte Kapazität, bewältigen aber burstigen Datenverkehr ohne Kapazitätsplanung. Für einen Dienst dieser Größenordnung verwenden wir bereitgestellte Kapazität mit Autoskalierung für die Basislast und On-Demand für Überlauf. - CDN und Edge-Computing erhöhen die Kosten, reduzieren aber die Anforderungen an die Ursprungsinfrastruktur erheblich und verbessern die Benutzererfahrung. Betriebskomplexität vs. Zuverlässigkeit: - Multi-Region-Bereitstellung mit DynamoDB Global Tables erhöht die betriebliche Komplexität, ist aber für das 99,99 %-Verfügbarkeitsziel und die Anforderung globaler geringer Latenz unerlässlich. - Kafka fügt ein weiteres zu betreibendes System hinzu, bietet aber die Entkopplung und Haltbarkeit, die für zuverlässige Analysen erforderlich sind. Speicher vs. Berechnung: - Wir aggregieren tägliche Analyseergebnisse vorab, anstatt sie on-the-fly aus rohen Klickereignissen zu berechnen. Dies tauscht Speichereffizienz gegen Abfrageleistung und Einfachheit ein. Eindeutigkeit benutzerdefinierter Aliase: - Benutzerdefinierte Aliase teilen sich denselben Namensraum wie generierte Codes. Wir reservieren den generierten Code-Bereich (genau 7 Base62-Zeichen) und verlangen, dass benutzerdefinierte Aliase entweder eine andere Länge haben oder gegen den generierten Bereich geprüft werden. Einfachere Vorgehensweise: Alle Codes (generiert und benutzerdefiniert) kommen in dieselbe Tabelle, und der bedingte Schreibvorgang stellt die Einzigartigkeit unabhängig davon sicher. 11. ZUSAMMENFASSUNG DER TECHNOLOGIENAUSWAHL - Globales Load Balancing: AWS Global Accelerator oder Cloudflare mit Anycast DNS - CDN und Edge: CloudFront oder Cloudflare mit Edge-Workern - Compute: Kubernetes-Cluster oder ECS/Fargate in jeder Region für zustandslose Dienste - Primärdatenbank: DynamoDB Global Tables (Link-Zuordnungen und tägliche Analysen) - Cache: ElastiCache Redis-Cluster in jeder Region - Nachrichtenwarteschlange: Amazon Kinesis oder Apache Kafka (MSK) für Klickereignisse - Analyse-Verarbeitung: Kafka Streams oder Flink für Echtzeit-Aggregation - ID-Generierung: Bereichsbasierter Zuweisungsdienst, unterstützt durch einen kleinen Koordinationsspeicher (DynamoDB oder ZooKeeper) - Überwachung: CloudWatch, Prometheus, Grafana, PagerDuty für Alarmierung Dieser Entwurf bewältigt die genannten Anforderungen mit einer klaren Trennung des Schreibpfads (Linkerstellung), des Lesepfads (Weiterleitungen) und des Analysepfads, die jeweils unabhängig skalierbar sind. Die mehrschichtige Caching-Strategie (Edge, regionales Redis, lokal) stellt sicher, dass selbst extremer viraler Datenverkehr reibungslos abgewickelt wird, während die Multi-Region-Architektur mit DynamoDB Global Tables die Haltbarkeits- und Verfügbarkeitsgarantien für eine SLA von 99,99 % bietet.

### 1. High-Level Architecture Das System ist als global verteilte Multi-Region-Architektur konzipiert, um niedrige Latenzzeiten und hohe Verfügbarkeit zu gewährleisten. Jede Region fungiert als eigenständiger Point of Presence (PoP). **Kernkomponenten:** * **Global Load Balancer (GLB):** Verwendet DNS-basiertes Routing (z. B. Latenz-basiert, Geo-basiert), um Benutzer zur nächstgelegenen gesunden Region zu leiten. * **CDN (Content Delivery Network):** Sitzt vor unseren Anwendungsservern, um Weiterleitungsantworten (HTTP 301) für beliebte Links am Edge zu cachen, wodurch die Latenz und die Last auf unserer Infrastruktur für virale Inhalte drastisch reduziert werden. * **Regional Load Balancer:** Verteilt den Datenverkehr innerhalb einer Region auf die zustandslosen Webserver. * **Webserver (API Gateway):** Beenden TLS und leiten Anfragen an den entsprechenden Backend-Dienst weiter. * **Redirect Service (Read Path):** Ein hochoptimierter, zustandsloser Microservice, der `GET /{short_id}`-Anfragen bearbeitet. Er führt eine Suche durch (zuerst Cache, dann Datenbank) und gibt eine Weiterleitung aus. Dies ist die kritischste und am stärksten frequentierte Komponente. * **Link Service (Write Path):** Ein Microservice, der `POST /api/v1/links` zur Erstellung neuer kurzer Links bearbeitet. Er koordiniert sich mit dem ID Generator und schreibt in die Datenbank. * **Analytics Service:** Ein Microservice, der Analysedaten über `GET /api/v1/links/{short_id}/analytics` bereitstellt. Er liest aus einem dedizierten Analysedaten-Speicher. * **ID Generator Service:** Ein dedizierter Dienst (z. B. basierend auf Snowflake), der global eindeutige, annähernd zeitlich sortierbare 64-Bit-IDs generiert, die für kurze Links verwendet werden. * **Message Queue (z. B. Kafka, AWS SQS):** Entkoppelt den kritischen Weiterleitungspfad von der nicht-kritischen Analyse-Verarbeitung. Der Redirect Service veröffentlicht für jede erfolgreiche Weiterleitung ein leichtgewichtiges "Klick-Ereignis" in die Warteschlange. * **Analytics Ingestion Processor:** Ein Consumer-Dienst, der aus der Message Queue liest, Klick-Ereignisse verarbeitet und den Analysedaten-Speicher sowie aggregierte Zähler aktualisiert. *(Link zum konzeptionellen Diagramm)* ### 2. Datenmodell und Speicherentscheidungen Wir werden zwei separate Datenspeicher verwenden, die für ihre spezifischen Zugriffsmuster optimiert sind. **A. Link Mapping Store** * **Wahl:** Ein verteilter NoSQL-Schlüssel-Wert-Speicher wie **Amazon DynamoDB** mit Global Tables oder **Apache Cassandra**. * **Begründung:** Diese Wahl wird durch die Notwendigkeit massiver Skalierbarkeit, hoher Verfügbarkeit und latenzarmer schlüsselbasierter Lookups bestimmt. Das primäre Lese-Muster ist eine direkte Suche nach `short_id`, was perfekt zu einem Schlüssel-Wert-Modell passt. Eine Multi-Region-, Multi-Master-Konfiguration (wie DynamoDB Global Tables) bietet latenzarme Lese- und Schreibvorgänge für globale Benutzer und integriertes Disaster Recovery. * **Schema (`links`-Tabelle): * `short_id` (String, Partition Key): Der eindeutige 7-Zeichen-Code oder benutzerdefinierte Alias. * `long_url` (String): Die Ziel-URL. * `created_at` (Timestamp): Erstellungszeitstempel. * `total_clicks` (Number): Ein atomarer Zähler für die gesamten Klicks während der Lebensdauer, aktualisiert durch den Analyseprozessor. **B. Analytics Data Store** * **Wahl:** Eine Wide-Column- oder Zeitreihen-Datenbank wie **Apache Cassandra** oder **Amazon Timestream**. * **Begründung:** Dieser Speicher muss einen sehr hohen Schreibdurchsatz von Klick-Ereignissen bewältigen und Daten effizient nach Zeitbereichen abfragen können (z. B. die letzten 30 Tage). Ein Wide-Column-Speicher ermöglicht es uns, dies effektiv zu modellieren. * **Schema (`clicks_by_day`-Tabelle): * `short_id` (String, Partition Key): Die Link-Identifikation. * `event_date` (String, Clustering Key, Format `YYYY-MM-DD`): Das Datum der Klicks. * `daily_count` (Counter): Ein verteilter Zähler für die Anzahl der Klicks an diesem Tag. Dieses voraggregierte Modell ist effizient für die erforderliche Abfrage ("Klicks pro Tag"). Rohdatenereignisse könnten bei Bedarf in einem günstigeren Objektspeicher (wie S3) zur langfristigen Archivierung gespeichert werden. ### 3. ID-Generierungsstrategie * **Generierte IDs:** Wir benötigen kurze, eindeutige, nicht-sequentielle IDs. Ein 7-Zeichen-String mit Base62-Kodierung (`[a-zA-Z0-9]`) bietet 62^7 (~3,5 Billionen) eindeutige Kombinationen, was für die erwarteten 7,2 Milliarden Links über 5 Jahre mehr als ausreichend ist. 1. Der **ID Generator Service** erzeugt eine global eindeutige 64-Bit-Integer (ähnlich wie Twitters Snowflake), die einen Zeitstempel, eine Region-/Maschinen-ID und eine Sequenznummer kombiniert. Dies vermeidet einen Single Point of Failure und Engpässe. 2. Der **Link Service** fordert eine ID vom Generator an. 3. Anschließend kodiert er die 64-Bit-Integer mit Base62, um den `short_id`-String zu erstellen. * **Benutzerdefinierte Aliase:** 1. Wenn ein Benutzer einen benutzerdefinierten Alias einreicht, führt der Link Service eine direkte Leseoperation in der `links`-Tabelle mit dem Alias als Schlüssel durch. 2. Wenn der Schlüssel nicht existiert, fährt er mit dem Schreiben des neuen Eintrags fort, indem er eine bedingte Schreiboperation verwendet (z. B. `put if not exists`), um Race Conditions zu verhindern, bei denen zwei Benutzer gleichzeitig denselben Alias beanspruchen. 3. Wenn der Schlüssel existiert, gibt er einen 409 Conflict-Fehler zurück. ### 4. API-Design Der Dienst stellt eine einfache RESTful API bereit. * **Kurzen Link erstellen:** `POST /api/v1/links` * **Anforderungs-Body:** `{"long_url": "https://example.com/very/long/path", "custom_alias": "my-link"}` (custom_alias ist optional) * **Erfolg (201 Created):** `{"short_url": "https://sho.rt/my-link", "long_url": "..."}` * **Fehler (409 Conflict):** Wenn der benutzerdefinierte Alias bereits vergeben ist. * **Benutzer weiterleiten:** `GET /{short_id}` * **Beispiel:** `GET /aB1x2Yc` * **Erfolg (301 Moved Permanently):** `Location: https://example.com/very/long/path` * **Fehler (404 Not Found):** Wenn die `short_id` nicht existiert. * **Analysen abrufen:** `GET /api/v1/links/{short_id}/analytics` * **Erfolg (200 OK):** `{"short_id": "aB1x2Yc", "total_clicks": 15023, "daily_clicks": [{"date": "2023-10-27", "clicks": 850}, {"date": "2023-10-26", "clicks": 1200}]}` ### 5. Caching, Partitionierung und Replikation * **Caching:** Eine mehrschichtige Caching-Strategie ist unerlässlich, um Lese-lastigen Datenverkehr und virale Hotspots zu bewältigen. 1. **CDN-Caching:** Das CDN speichert `301` Weiterleitungsantworten am Edge. Dies ist die erste Verteidigungslinie und bewältigt den Großteil des Datenverkehrs für beliebte Links. 2. **In-Memory-Cache:** Jede Region verfügt über einen verteilten Cache (z. B. **Redis Cluster**), der `short_id -> long_url`-Zuordnungen speichert. Der Redirect Service folgt einem Read-Through-Muster: Zuerst Redis prüfen und bei einem Miss die Datenbank abfragen und den Cache mit einer TTL (z. B. 24 Stunden) füllen. 3. **Negative Caching:** Cache "nicht gefunden"-Ergebnisse für kurze Zeit (z. B. 5 Minuten), um wiederholte Datenbankabfragen für ungültige oder gelöschte Links zu verhindern. * **Partitionierung:** Die NoSQL-Datenbanken (DynamoDB/Cassandra) partitionieren Daten automatisch basierend auf dem `short_id`-Hash. Dies verteilt die Daten- und I/O-Last horizontal über den Cluster und ermöglicht massive Skalierung. * **Replikation:** Die primäre `links`-Datenbank wird in einer Multi-Master-Konfiguration über alle aktiven Regionen repliziert. Dies stellt sicher, dass ein in einer Region erstellter Link schnell für die Weiterleitung in allen anderen Regionen verfügbar ist, was latenzarme Lesevorgänge weltweit und hohe Datenhaltbarkeit bietet. ### 6. Zuverlässigkeit und Skalierung * **Zuverlässigkeit:** * **Multi-Region Active-Active:** Der gesamte Stack wird in mindestens drei geografisch getrennten Regionen bereitgestellt. Der GLB führt Gesundheitsprüfungen durch und leitet den Datenverkehr automatisch von jeder ausfallenden Region weg, sodass der Dienst einen vollständigen regionalen Ausfall überstehen kann. * **Zustandslose Dienste:** Alle Dienste (Redirect, Link, Analytics) sind zustandslos, was es ihnen ermöglicht, horizontal skaliert und bei Ausfall einer Instanz leicht ersetzt zu werden. * **Entkopplung:** Die Message Queue stellt sicher, dass eine Verlangsamung oder ein Ausfall der Analyse-Pipeline die kritische, benutzerorientierte Weiterleitungsfunktionalität nicht beeinträchtigt. * **Skalierung für Leseverkehr:** 1. **CDN:** Das CDN absorbiert den Großteil der Anfragen für virale Links. 2. **Horizontale Skalierung:** Der zustandslose Redirect Service kann durch Hinzufügen weiterer Instanzen hinter dem regionalen Load Balancer skaliert werden. 3. **Cache-Skalierung:** Der verteilte Cache kann durch Hinzufügen weiterer Knoten zum Cluster skaliert werden. 4. **Datenbank-Skalierung:** Die partitionierte NoSQL-Datenbank skaliert durch Hinzufügen weiterer Knoten. ### 7. Wichtige Kompromisse * **Konsistenz vs. Verfügbarkeit:** Wir priorisieren Verfügbarkeit gegenüber starker Konsistenz. Die Verwendung einer Multi-Master-Datenbank bedeutet, dass Schreibkonflikte möglich sind (wenn auch für diesen Anwendungsfall selten). Eventual Consistency ist für die Link-Propagation über Regionen hinweg akzeptabel und für die Analysedaten erforderlich (bis zu 10 Minuten Verzögerung). * **Kosten vs. Leistung:** Eine globale, Multi-Region-, Active-Active-Architektur mit einem CDN und mehreren Datenspeichern ist teuer. Sie ist jedoch notwendig, um die strengen Anforderungen an 99,99 % Verfügbarkeit und globale niedrige Latenz zu erfüllen. Ein günstigeres Single-Region-Design wäre nicht ausreichend. * **Betriebliche Komplexität:** Die Microservices-Architektur erhöht die Komplexität in Bezug auf Bereitstellung, Überwachung und Wartung im Vergleich zu einem Monolithen. Dieser Kompromiss wird eingegangen, um unabhängige Skalierbarkeit, Fehlertoleranz und Ausfallsicherheit für verschiedene Teile des Systems zu erreichen.