Entwerfen Sie einen globalen URL-Kürzungsdienst

Antwort: 1. Architektur auf hoher Ebene und Request-Flows: **Hauptkomponenten:** * **API-Gateway/Load-Balancer:** Einstiegspunkt für alle Benutzeranfragen; übernimmt Routing, Authentifizierung und Rate Limiting. * **Shorten Service:** Microservice, der für das Erstellen, Aktualisieren und Löschen von Kurzlinks verantwortlich ist. Behandelt die Validierung benutzerdefinierter Aliase und die Ablauf-Logik. * **Redirect Service:** Microservice, der für Redirections mit hohem Durchsatz und niedriger Latenz optimiert ist. Erfasst Klickereignisse. * **Verteilter Cache (z. B. Redis Cluster):** Primärer Speicher für Zuordnungen von `short_code` zu `long_url`, um Redirects mit minimaler Latenz zu bedienen. * **Verteilte SQL-Datenbank (z. B. CockroachDB, Google Spanner):** Speichert die maßgebliche Source of Truth für sämtliche Link-Metadaten und gewährleistet globale Eindeutigkeit sowie starke Konsistenz. * **Message Queue (z. B. Apache Kafka):** Nimmt hochvolumige Klickereignisse aus dem Redirect Service auf und entkoppelt ihn von der Analytics-Verarbeitung. * **Analytics Processor (z. B. Apache Flink/Spark Streaming):** Verarbeitet Klickereignisse aus der Message Queue, führt Echtzeit-Aggregation durch und speichert die Daten. * **Data Warehouse (z. B. ClickHouse, Snowflake, BigQuery):** Speichert rohe und aggregierte Analytics-Daten für Reporting und Analyse. * **CDN (z. B. Cloudflare, Akamai):** Verteilt statische Assets, stellt globale DNS-Auflösung bereit und kann Geo-Routing zum nächstgelegenen Rechenzentrum anbieten. **Request-Flows:** * **Erstellung von Kurzlinks:** 1. Der Benutzer/Client sendet eine Anfrage an das API-Gateway. 2. Das API-Gateway leitet an einen Load-Balancer und dann an den Shorten Service weiter. 3. Der Shorten Service generiert einen eindeutigen `short_code` (oder validiert einen benutzerdefinierten Alias). 4. Er speichert `short_code`, `long_url`, `expires_at` und weitere Metadaten in der verteilten SQL-Datenbank. 5. Er schreibt die neue Zuordnung `short_code` -> `long_url` in den verteilten Cache. 6. Der Shorten Service gibt den `short_code` an den Benutzer zurück. * **Kurzlink-Weiterleitung:** 1. Der Benutzer/Client ruft eine Kurz-URL auf, die über CDN/GeoDNS zum Load-Balancer des nächstgelegenen Rechenzentrums geroutet wird. 2. Der Load-Balancer leitet an den Redirect Service weiter. 3. Der Redirect Service prüft zuerst im verteilten Cache die Zuordnung `short_code` -> `long_url`. 4. *Cache-Hit:* Falls gefunden und aktiv, gibt er sofort eine HTTP-301/302-Weiterleitung auf die `long_url` zurück. 5. *Cache-Miss:* Falls nicht gefunden, fragt er die verteilte SQL-Datenbank ab. Falls gefunden und aktiv, befüllt er den Cache und leitet dann weiter. Falls nicht gefunden, abgelaufen oder gelöscht, gibt er einen 404-Fehler zurück. 6. Asynchron veröffentlicht der Redirect Service ein Klickereignis (mit `short_code`, `timestamp`, `country`, `device_type`, `referrer_domain`) in der Message Queue. * **Analytics-Verarbeitung:** 1. Der Analytics Processor verarbeitet Klickereignisse aus der Message Queue. 2. Er führt Echtzeitverarbeitung durch (z. B. Aggregation, Anreicherung). 3. Rohdaten und aggregierte Daten werden für Reporting im Data Warehouse gespeichert. 2. Datenmodell und Speicherentscheidungen: * **Links & Aliase (verteilte SQL-Datenbank - CockroachDB/Google Spanner):** * **Tabelle `links`:** * `short_code` (VARCHAR, Primärschlüssel): Der eindeutige Kurzbezeichner. * `long_url` (VARCHAR): Die ursprüngliche URL (bis zu 500 Bytes). * `user_id` (UUID, indiziert, FK): Optional, für Eigentümerschaft des Links. * `created_at` (TIMESTAMP): Zeitpunkt der Link-Erstellung. * `expires_at` (TIMESTAMP, nullable, indiziert): Zeitpunkt, zu dem der Link ablaufen soll. * `status` (ENUM: 'active', 'expired', 'deleted', indiziert): Aktueller Zustand des Links. * `is_custom_alias` (BOOLEAN): True, wenn es sich um einen benutzerdefinierten Alias handelt. * `click_count` (BIGINT): Denormalisierte, schließlich konsistente Anzahl von Klicks (durch Analytics aktualisiert). * *Begründung:* Gewählt wegen starker Konsistenzgarantien (kritisch für die globale Eindeutigkeit von `short_code` und `custom_alias`), ACID-Eigenschaften und nativer Multi-Region-Replikationsfähigkeiten. Das vereinfacht das globale Datenmanagement und stellt die Datenintegrität sicher. * **Analytics-Ereignisse (Message Queue - Apache Kafka, Data Warehouse - ClickHouse/Snowflake):** * **Kafka-Topic (`click_events`):** Speichert rohe Klickereignis-Nachrichten (z. B. JSON/Protobuf). * **Data Warehouse (Tabelle `raw_clicks`):** * `event_id` (UUID, Primärschlüssel) * `short_code` (VARCHAR, indiziert) * `timestamp` (TIMESTAMP, indiziert) * `country` (VARCHAR, indiziert) * `device_type` (VARCHAR) * `referrer_domain` (VARCHAR) * **Data Warehouse (Tabelle `aggregated_clicks`):** (z. B. stündliche/tägliche Aggregate) * `short_code` (VARCHAR, PK) * `aggregation_time` (TIMESTAMP, PK) * `country` (VARCHAR, PK) * `total_clicks` (BIGINT) * *Begründung:* Kafka bietet hochdurchsatzfähige, fehlertolerante Aufnahme und Entkopplung. ClickHouse/Snowflake sind für analytische Abfragen über massive Datensätze optimiert und unterstützen die Anforderung der Eventual Consistency für Analytics. 3. Skalierungsstrategie für leseintensiven Traffic: * **Verteilter Cache (Redis Cluster):** Dies ist die primäre Skalierungsebene für Redirects. Er speichert Zuordnungen von `short_code` zu `long_url` im Arbeitsspeicher und verarbeitet den Großteil der 4 Milliarden täglichen Redirects. Redis Cluster bietet horizontale Skalierung und hohe Verfügbarkeit durch Sharding und Replikation. * **Globales CDN und Geo-Routing:** Ein CDN (z. B. Cloudflare) bedient statische Assets und stellt intelligentes DNS-basiertes Routing (GeoDNS) bereit, um Benutzer zum geografisch nächstgelegenen Rechenzentrum zu leiten und so die Redirect-Latenz zu minimieren. * **Zustandslose Services:** Sowohl Shorten- als auch Redirect-Services sind zustandslos konzipiert, was eine einfache horizontale Skalierung durch Hinzufügen weiterer Instanzen hinter Load-Balancern in jeder Region ermöglicht. Auto-Scaling-Gruppen passen die Kapazität dynamisch auf Basis des Traffics an. * **Datenbank-Lesereplikate/verteilte Lesezugriffe:** Die verteilte SQL-Datenbank verarbeitet verteilte Lesezugriffe inhärent über ihre Knoten hinweg. Falls die Cache-Hit-Rate niedriger ausfällt als erwartet oder bei weniger populären Links, ist die Fähigkeit der Datenbank, Lesezugriffe über ihren Cluster zu skalieren, entscheidend. * **Short-Code-Generierung:** Für die Erstellung großer Linkvolumina können Short Codes chargenweise vorgeneriert und gespeichert werden, oder es kann ein verteilter ID-Generierungsdienst (z. B. nach dem Vorbild von Twitter Snowflake) verwendet werden, um eindeutige, nicht sequenzielle Codes sicherzustellen und Hotspots in der Datenbank zu verhindern. 4. Zuverlässigkeitsstrategie: * **Failover:** * **Multi-Region-Deployment:** Alle kritischen Services (Shorten, Redirect, Datenbank, Cache, Message Queue) werden in einer Active-Active-Konfiguration über mindestens drei geografisch getrennte Regionen hinweg bereitgestellt (z. B. Nordamerika, Europa, Asien). * **Failover auf Service-Ebene:** Services werden in Auto-Scaling-Gruppen über mehrere Availability Zones innerhalb jeder Region hinweg bereitgestellt. Load-Balancer erkennen automatisch ungesunde Instanzen und leiten Traffic von ihnen weg. * **Datenbank-Failover:** Die verteilte SQL-Datenbank bietet integrierte Multi-Region-Replikation und automatische Failover-Mechanismen (z. B. Raft-Konsens in CockroachDB), um auch dann einen kontinuierlichen Betrieb sicherzustellen, wenn Knoten oder ganze Zonen ausfallen. * **Cache-Failover:** Redis Cluster bietet Replikation für Datenredundanz und automatisches Failover von Master-Knoten. * **Message-Queue-Failover:** Kafka-Cluster werden mit Replikation (z. B. 3 Broker, Replikationsfaktor 3) über mehrere Availability Zones hinweg bereitgestellt, um Broker-Ausfälle zu tolerieren. * **Konsistenzentscheidungen:** * **Starke Konsistenz (Link-Erstellung/Aliase):** Die verteilte SQL-Datenbank gewährleistet starke Konsistenz für die Eindeutigkeit von `short_code` und `custom_alias`. Dies ist entscheidend, um Kollisionen zu verhindern und die Datenintegrität zu wahren. * **Eventual Consistency (Redirects):** Der verteilte Cache arbeitet mit Eventual Consistency. Wenn ein Link erstellt, aktualisiert (z. B. Änderung von `expires_at`) oder gelöscht wird, wird ein Ereignis in ein Cache-Invalidierungs-Topic (z. B. Kafka) veröffentlicht. Cache-Knoten abonnieren dieses Topic und invalidieren/aktualisieren ihre Einträge. Eine kurze TTL (z. B. 1–5 Minuten) auf Cache-Einträgen dient als Fallback, um unbefristete Veraltung zu verhindern. * **Eventual Consistency (Analytics):** Analytics-Daten sind innerhalb von 5 Minuten schließlich konsistent, verarbeitet durch die asynchrone Message Queue und Stream-Verarbeitung. Dies priorisiert Redirect-Performance gegenüber sofortigen Analytics-Updates. * **Umgang mit regionalen Ausfällen:** * **Globales Load Balancing/DNS:** Intelligente DNS-Dienste (z. B. GeoDNS) und globale Load-Balancer erkennen regionale Ausfälle automatisch und leiten Traffic in gesunde, aktive Regionen um. * **Datenreplikation:** Die verteilte SQL-Datenbank repliziert sämtliche Link-Daten über aktive Regionen hinweg. Wenn eine Region nicht verfügbar wird, können andere Regionen Anfragen mit minimalem Datenverlust und geringer Latenzauswirkung weiter bedienen. * **Graceful Degradation:** Wenn der Analytics Service oder die Message Queue Probleme hat, ist der Redirect Service so ausgelegt, dass er weiter funktioniert, indem er Ereignisse lokal puffert oder sie im Extremfall verwirft; dabei wird die Kernfunktionalität der Weiterleitung priorisiert. 5. Wichtige Trade-offs, Engpässe und Risiken: * **Wichtige Trade-offs:** * **Konsistenz vs. Latenz:** Starke Konsistenz bei der Link-Erstellung (über verteilte SQL-Datenbank) gewährleistet Datenintegrität, kann aber zu etwas höherer Schreib-Latenz führen. Für Redirects wird Eventual Consistency über einen hochoptimierten Cache gewählt, um eine Latenz unter 80 ms zu erreichen. * **Cache-Größe vs. Kosten:** Umfangreiches Caching ist für die Redirect-Performance essenziell, erfordert jedoch erhebliche Speicherressourcen und führt damit zu höheren Infrastrukturkosten. Es muss ein Gleichgewicht zwischen Cache-Hit-Rate und Betriebskosten gefunden werden. * **Short-Code-Länge vs. Namespace-Größe:** Kürzere Codes sind benutzerfreundlicher, erhöhen jedoch die Wahrscheinlichkeit von Kollisionen und begrenzen die Gesamtzahl eindeutiger Links. Ein Base62-Code mit 7–10 Zeichen bietet einen großen, praktischen Namespace. * **Engpässe:** * **Kapazität des verteilten Caches:** Wenn der Cache den Spitzen-Lesedurchsatz nicht verarbeiten kann oder wenn das aktive Working Set an Links seine Speicherkapazität überschreitet, fallen Redirects auf die Datenbank zurück, was Latenz und Datenbanklast erhöht. * **Datenbank-Schreibdurchsatz:** Obwohl die Link-Erstellung ein geringeres Volumen als Redirects hat, sind 120 Millionen Links/Tag erheblich. Die verteilte SQL-Datenbank muss in der Lage sein, diese Schreiblast über Regionen hinweg zu bewältigen, ohne zum Engpass zu werden. * **Netzwerklatenz zwischen Regionen:** Regionenübergreifende Datenreplikation und Konsistenzprüfungen, insbesondere bei Schreiboperationen in einem global verteilten System, können inhärente Latenz verursachen. * **Risiken & Gegenmaßnahmen:** * **Risiko 1: Short-Code-Kollisionen (insbesondere bei zufälliger Generierung):** * *Gegenmaßnahme:* Verwenden Sie einen ausreichend langen `short_code` (z. B. 7–10 Zeichen mit Base62: a-z, A-Z, 0-9). Implementieren Sie eine robuste Generierungsstrategie: einen großen Pool eindeutiger Codes vorgenerieren, einen verteilten ID-Generator (z. B. Snowflake-ähnlich) verwenden, um eindeutige IDs zu erzeugen und diese dann in Base62 umzuwandeln, oder bei benutzerdefinierten Aliasen eine direkte Eindeutigkeitsprüfung in der Datenbank mit optimistischem Locking und Wiederholungsversuchen durchführen. * **Risiko 2: Cache-Veraltung bei abgelaufenen/gelöschten Links:** * *Gegenmaßnahme:* Implementieren Sie einen Echtzeitmechanismus zur Cache-Invalidierung. Wenn sich der Status eines Links ändert (z. B. `expires_at` erreicht, `status` auf 'deleted' gesetzt), veröffentlicht der Shorten Service (oder ein dedizierter Hintergrundjob) ein Ereignis in ein Kafka-Topic. Alle Redirect-Service-Instanzen und Cache-Knoten abonnieren dieses Topic und invalidieren den entsprechenden `short_code`-Eintrag sofort. Eine kurze TTL (z. B. 1–5 Minuten) auf Cache-Einträgen dient als Fallback. * **Risiko 3: Datenbank-Hotspots aufgrund ungleichmäßiger `short_code`-Verteilung:** * *Gegenmaßnahme:* Bei verteilten SQL-Datenbanken auf deren interne Sharding- und Rebalancing-Fähigkeiten vertrauen. Bei benutzerdefinierten Aliasen dient der Alias selbst als Primärschlüssel, was für eine gute Verteilung sorgen sollte. Bei zufällig generierten Short Codes sicherstellen, dass der Generierungsalgorithmus ausreichend zufällige Codes erzeugt, um sequenzielle Schlüssel zu vermeiden, die zu Hotspots führen könnten. Datenbankpartitionen überwachen und bei Bedarf neu ausbalancieren. 6. Kapazitätsschätzung: * **Durchsatz:** * **Redirects:** 4 Milliarden/Tag = ~46.300 Anfragen/Sekunde (Durchschnitt), Spitze ~138.900 Anfragen/Sekunde (3x Durchschnitt). * **Link-Erstellung:** 120 Millionen/Tag = ~1.389 Anfragen/Sekunde (Durchschnitt), Spitze ~4.167 Anfragen/Sekunde (3x Durchschnitt). * **Aufnahme von Analytics-Ereignissen:** ~46.300 Ereignisse/Sekunde (Durchschnitt), Spitze ~138.900 Ereignisse/Sekunde. * **Speicher:** * **Link-Daten (verteilte SQL-Datenbank):** * Durchschnittliche Datensatzgröße: ~100 Bytes (`short_code`, `long_url`, Zeitstempel, Status usw.). * Täglich neue Links: 120 Millionen * 100 Bytes = 12 GB. * Gesamt über 5 Jahre: 12 GB/Tag * 365 Tage/Jahr * 5 Jahre = ~21,9 TB. * Mit 3x-Replikationsfaktor für hohe Verfügbarkeit/Multi-Region: ~65,7 TB. * **Analytics-Daten (Data Warehouse):** * Durchschnittliche Ereignisgröße: ~100 Bytes (`short_code`, Zeitstempel, Land, Gerät, Referrer). * Tägliche Ereignisse: 4 Milliarden * 100 Bytes = 400 GB. * Gesamt bei 1 Jahr Aufbewahrung: 400 GB/Tag * 365 Tage/Jahr = ~146 TB. * Mit 3x-Replikationsfaktor: ~438 TB. * **Verteilter Cache (Redis Cluster):** * Jeder gecachte Eintrag: `short_code` (z. B. 10 Bytes) + `long_url` (durchschnittlich 500 Bytes) = ~510 Bytes. * Um 1 Milliarde aktive Links zu cachen (ein angemessenes Working Set für populäre Links): 1 Milliarde Links * 510 Bytes/Link = 510 GB Cache-Speicher. Dies ist eine erhebliche, aber für einen großen, geshardeten Redis Cluster beherrschbare Größe.

## Global URL Shortening Service - System Design ### 1. High-Level Architecture **Main Components:** - **API Gateway & Load Balancer**: Global entry point with regional routing (North America, Europe, Asia) - **Short Link Service**: Handles creation, validation, and alias management - **Redirect Service**: Optimized for high-throughput redirects with minimal latency - **Cache Layer**: Multi-tier caching (edge CDN, regional Redis, local in-memory) - **Primary Data Store**: Distributed SQL database (PostgreSQL with sharding) for link metadata - **Analytics Pipeline**: Event streaming (Kafka) → Stream processor (Flink/Spark) → Analytics DB (ClickHouse/Druid) - **CDN**: Global content delivery for redirect responses - **Message Queue**: For async operations (expiration, deletion, analytics) - **Monitoring & Observability**: Distributed tracing, metrics, alerting **Request Flows:** *Create Short Link:* 1. Client → API Gateway (regional) 2. Short Link Service validates input, generates short code or validates custom alias 3. Check alias uniqueness in distributed cache + primary DB 4. Write to primary DB (with replication) 5. Invalidate cache, publish event to Kafka 6. Return short link (p95 < 300ms) *Redirect (Read):* 1. Client → Nearest CDN edge location 2. CDN checks local cache; if miss, routes to regional cache (Redis) 3. Regional cache miss → Query primary DB with read replica 4. Response cached at CDN edge and regional Redis 5. Return 301/302 redirect (p95 < 80ms) 6. Async: publish click event to Kafka *Analytics:* 1. Click events → Kafka topic 2. Stream processor aggregates by link_id, country, device, referrer 3. Write aggregated metrics to analytics DB every 1-5 minutes 4. Dashboard queries analytics DB for reports --- ### 2. Data Model and Storage Choices **Link Metadata Table (Primary DB - PostgreSQL):** ``` links: - link_id (UUID, primary key) - short_code (VARCHAR(10), unique index) - long_url (TEXT, max 500 bytes) - user_id (UUID, indexed) - custom_alias (VARCHAR(100), unique global index, nullable) - created_at (TIMESTAMP) - expires_at (TIMESTAMP, nullable, indexed) - is_deleted (BOOLEAN, indexed) - is_custom (BOOLEAN) - created_region (VARCHAR(10)) - metadata (JSONB: title, description, tags) ``` **Analytics Events Table (Time-series DB - ClickHouse):** ``` click_events: - event_id (UUID) - link_id (UUID, indexed) - timestamp (DateTime) - country (VARCHAR(2)) - device_type (VARCHAR(20)) - referrer_domain (VARCHAR(255)) - user_agent (VARCHAR(500)) - ip_hash (VARCHAR(64)) ``` **Storage Choices Justification:** - **PostgreSQL (Primary)**: ACID guarantees for link creation, strong consistency for alias uniqueness, proven at scale with proper sharding - **Redis (Regional Cache)**: Sub-millisecond latency for hot links, supports TTL for automatic expiration, distributed across regions - **ClickHouse (Analytics)**: Optimized for time-series analytics, columnar storage reduces storage by 10-100x, fast aggregations - **CDN (Cloudflare/Akamai)**: Global edge caching, reduces latency to <80ms p95, offloads origin traffic - **Kafka (Event Stream)**: Decouples analytics from redirect path, enables replay, supports multiple consumers --- ### 3. Scaling Strategy for Read-Heavy Traffic **Caching Architecture (Multi-Tier):** 1. **Edge CDN Cache** (Tier 1): - Cache redirect responses globally - TTL: 24 hours for active links, 5 minutes for expired links - Cache key: short_code - Hit ratio target: 95%+ - Reduces origin traffic by 95% 2. **Regional Redis Cluster** (Tier 2): - 3 regions: us-east, eu-west, ap-southeast - Each region: Redis cluster with 6 nodes (3 primary, 3 replica) - Replication across availability zones - TTL: 1 hour for links, 5 minutes for expired links - Capacity: 500GB per region (hot links only) 3. **Local In-Memory Cache** (Tier 3): - Per-service instance LRU cache (100MB) - Reduces Redis round-trips for hottest 1% of links **Read Replica Strategy:** - Primary DB in us-east (write master) - Read replicas in eu-west, ap-southeast (async replication, ~100ms lag) - Route reads to nearest replica - Fallback to primary if replica unavailable **Horizontal Scaling:** - Redirect Service: Auto-scale to 1000+ instances across regions - Each instance handles ~4M redirects/day (4B / 1000) - Load balancer distributes based on latency and capacity **Short Code Generation:** - Base62 encoding (0-9, a-z, A-Z) for 6-character codes - 62^6 = 56 billion possible codes (sufficient for 120M/day for 400+ years) - Distributed ID generator (Snowflake-like) with region prefix to avoid collisions - Batch allocation: each service instance pre-allocates 10K codes --- ### 4. Reliability Strategy **Failover & High Availability:** - **Multi-region deployment**: Active-active in 3 regions - **Database replication**: PostgreSQL streaming replication with automatic failover (Patroni) - **Circuit breakers**: Prevent cascading failures when cache/DB unavailable - **Graceful degradation**: If analytics DB down, still serve redirects; queue events locally **Consistency Decisions:** - **Strong consistency for writes**: Link creation uses distributed locks (Redis/Zookeeper) for alias uniqueness - **Eventual consistency for reads**: Redirect responses may be stale by ~100ms (acceptable) - **Eventual consistency for analytics**: 5-minute window acceptable per requirements - **Expiration handling**: Lazy deletion (check expires_at on read) + background job (scan every hour) **Regional Outage Handling:** 1. **Detect outage**: Health checks fail for 30 seconds 2. **Failover**: Route traffic to other regions 3. **Write operations**: Redirect to primary region (us-east) with fallback to local region 4. **Read operations**: Use read replicas in other regions 5. **Recovery**: Sync data from primary when region recovers 6. **Monitoring**: Alert on region unavailability, track failover events **Specific Mitigations:** - **Database failure**: Patroni auto-failover to replica (RTO < 30s) - **Cache failure**: Bypass to DB with rate limiting to prevent thundering herd - **CDN failure**: Direct traffic to regional cache - **Network partition**: Assume partition heals; use quorum-based decisions - **Data corruption**: Point-in-time recovery from backups (daily snapshots) --- ### 5. Key Trade-offs, Bottlenecks, and Risks **Trade-offs:** 1. **Consistency vs. Latency**: Chose eventual consistency for analytics to keep redirect latency <80ms. Strong consistency for alias uniqueness adds ~50ms but necessary for correctness. 2. **Cache TTL vs. Freshness**: 24-hour CDN TTL reduces origin load but means expired links may redirect for up to 24 hours. Mitigated by 5-minute TTL for links marked deleted. 3. **Storage vs. Query Speed**: Denormalize analytics data (store country, device in events table) to enable fast aggregations, accepting 2-3x storage overhead. 4. **Regional Autonomy vs. Global Consistency**: Each region can serve reads independently but writes must coordinate for alias uniqueness, adding latency. **Bottlenecks:** 1. **Alias Uniqueness Check**: Global distributed lock required; can become contention point during peak writes. Mitigation: Use Redis with Lua scripts for atomic check-and-set; shard by first character of alias. 2. **Database Write Throughput**: 120M new links/day = ~1,400 writes/sec. PostgreSQL can handle ~10K writes/sec per instance, so need 1-2 primary instances. Mitigation: Batch writes, use connection pooling (PgBouncer). 3. **Analytics Pipeline**: 4B clicks/day = ~46K events/sec. Kafka can handle this, but aggregation may lag. Mitigation: Use stream processor (Flink) for real-time aggregation; write to analytics DB every 1 minute. **Three Major Risks & Mitigations:** **Risk 1: Cache Stampede on Popular Link Expiration** - *Scenario*: Viral link with 1M clicks/hour expires; all cache entries invalidate simultaneously; 1M requests hit DB - *Impact*: DB overload, redirect latency spikes to seconds, SLA breach - *Mitigation*: - Use probabilistic early expiration: refresh cache 5 minutes before actual expiration - Implement request coalescing: if multiple requests hit expired link, only first queries DB - Set max DB query rate with circuit breaker; return 404 if exceeded - Pre-warm cache for known expiring links **Risk 2: Distributed Alias Collision Under Network Partition** - *Scenario*: Network partition between regions; two users create same custom alias in different regions; partition heals; data conflict - *Impact*: Alias uniqueness violated; one link becomes unreachable; data inconsistency - *Mitigation*: - Use global distributed lock (Zookeeper/etcd) for alias writes; fail if lock unavailable - Implement conflict resolution: timestamp-based winner (earlier write wins) - Audit job: scan for duplicate aliases daily; alert on conflicts - Require alias writes to go through primary region only (accept higher latency) **Risk 3: Analytics Data Loss During Stream Processing Failure** - *Scenario*: Kafka consumer crashes; events not processed; analytics lag grows; memory fills; events dropped - *Impact*: Inaccurate click counts; business metrics unreliable; customer trust loss - *Mitigation*: - Use Kafka consumer groups with offset management; resume from last committed offset - Implement dead-letter queue for failed events; replay manually - Set memory limits on local event buffer; drop oldest events if full (with alerting) - Dual-write analytics: Kafka → Stream processor AND direct DB writes (with deduplication) - Monitor consumer lag; alert if lag > 5 minutes --- ### 6. Capacity Estimates **Storage:** *Link Metadata (PostgreSQL):* - 120M new links/day × 365 days = 43.8B links/year - Per link: 50 bytes (IDs, timestamps, flags) + 500 bytes (long URL) + 100 bytes (metadata) = 650 bytes - Year 1: 43.8B × 650B = 28.5 TB - With 3-year retention: 85.5 TB - With replication (3x): 256.5 TB - Sharded across 10 instances: 25.6 TB per instance (manageable) *Analytics Events (ClickHouse):* - 4B clicks/day × 365 days = 1.46T events/year - Per event: 50 bytes (IDs, timestamps) + 100 bytes (country, device, referrer) = 150 bytes - Year 1: 1.46T × 150B = 219 TB (uncompressed) - ClickHouse compression: 10-20x → 11-22 TB/year - 3-year retention: 33-66 TB (acceptable) *Cache (Redis):* - Hot links (1% of total): 438M links - Per link in cache: 50 bytes (short_code, long_url pointer) = 50 bytes - 438M × 50B = 22 GB per region - 3 regions: 66 GB total (fits in 500GB per region allocation) **Throughput:** *Write Throughput:* - 120M links/day ÷ 86,400 seconds = 1,389 writes/sec - PostgreSQL: 1 primary instance handles 10K writes/sec → 1 instance sufficient - Kafka: 1,389 events/sec → 1 partition sufficient (Kafka handles 100K+ msgs/sec per partition) *Read Throughput:* - 4B redirects/day ÷ 86,400 seconds = 46,296 reads/sec - Peak (3x): 138,888 reads/sec - CDN cache hit rate: 95% → 6,944 reads/sec to origin - Redis hit rate: 99% of misses → 70 reads/sec to DB - PostgreSQL: 1 read replica per region handles 10K reads/sec → 1 replica per region sufficient - Redirect Service instances: 46K reads/sec ÷ 100 reads/sec per instance = 460 instances (baseline); 1,389 instances at peak *Analytics Throughput:* - 4B clicks/day = 46,296 events/sec - Kafka: 1 topic, 10 partitions (parallelism) - Stream processor: 10 instances, each handles 4,630 events/sec - ClickHouse: Batch inserts every 1 minute; 46K events/min = manageable **Network Bandwidth:** *Redirect responses:* - 46K redirects/sec × 300 bytes (HTTP response) = 13.8 MB/sec - Peak: 41.4 MB/sec - CDN absorbs 95% → 2.1 MB/sec to origin at peak - Easily handled by 1 Gbps connection *Analytics events:* - 46K events/sec × 500 bytes = 23 MB/sec - Kafka cluster: 10 Gbps capacity → sufficient **Summary Table:** | Component | Capacity | Instances | Notes | |-----------|----------|-----------|-------| | PostgreSQL Primary | 10K writes/sec | 1 | Sharded for future growth | | PostgreSQL Read Replicas | 10K reads/sec | 3 (1 per region) | Async replication | | Redis Clusters | 100K ops/sec | 3 (1 per region) | 6 nodes each | | Redirect Service | 100 redirects/sec | 460 (baseline), 1,389 (peak) | Auto-scaling | | Kafka Brokers | 100K msgs/sec | 3 | Replication factor 3 | | Stream Processors | 4,630 events/sec | 10 | Flink/Spark | | ClickHouse Nodes | 1M inserts/sec | 3 | Distributed cluster | | CDN Edge Locations | Global | 200+ | Cloudflare/Akamai | --- ### 7. Implementation Priorities 1. **Phase 1** (MVP): Single region, PostgreSQL + Redis + CDN, basic analytics 2. **Phase 2** (Scale): Multi-region, read replicas, Kafka analytics pipeline 3. **Phase 3** (Optimize): Distributed ID generation, advanced caching, ClickHouse analytics 4. **Phase 4** (Harden): Circuit breakers, chaos engineering, disaster recovery drills