Progettazione di un sistema di accorciamento URL: come funzionano gli accorciatori di link dietro le quinte

"Progetta un accorciatore di URL" è una delle domande più popolari nei colloqui di system design — e per una buona ragione. Tocca hashing, database, caching, load balancing e sistemi distribuiti, il tutto in un prodotto apparentemente semplice.

In questa guida, esamineremo come funzionano effettivamente gli accorciatori di URL, le decisioni di progettazione chiave e i compromessi coinvolti in caso di scalabilità.

Un accorciatore di URL fa due cose:

1. 1Accorciare: Prendi un URL lungo e genera un codice breve
2. 2Reindirizzare: Quando qualcuno visita l'URL breve, reindirizzalo all'originale

Ecco il flusso di alto livello:

L'utente crea un link breve:
  URL lungo → Genera codice breve → Memorizza mapping → Restituisci URL breve

L'utente fa clic sul link breve:
  URL breve → Cerca il codice → Trova URL lungo → Reindirizzamento 301

La sfida principale è generare codici univoci e brevi. Ci sono diversi approcci:

Converti un ID auto-incrementante in una stringa Base62 utilizzando i caratteri [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

Un codice Base62 di 7 caratteri supporta 62^7 = 3,5 trilioni di URL univoci.

Pro: Semplice, lunghezza prevedibile, nessuna collisione Contro: Gli ID sequenziali sono prevedibili (gli utenti possono indovinare altri URL brevi)

Applica una funzione di hash (MD5, SHA-256) all'URL lungo e prendi i primi N caratteri:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Codice breve: "a3f2b8c"

Pro: Lo stesso input produce sempre lo stesso output (deduplicazione) Contro: Le collisioni di hash richiedono gestione; la lunghezza hash fissa potrebbe sprecare spazio

Genera una stringa alfanumerica casuale e controlla l'unicità:

Pro: Semplice, imprevedibile Contro: Richiede il controllo delle collisioni ad ogni creazione; diventa più lento man mano che il database si riempie

La maggior parte dei sistemi di produzione utilizza la codifica Base62 con un generatore di ID distribuito. È semplice, senza collisioni e performante. In Linkly, usiamo un approccio simile — puoi leggere di più su come funzionano gli accorciatori di URL per una panoramica meno tecnica.

La tabella principale è semplice:

urls ├── id (chiave primaria, auto-incrementante) ├── short_code (indice univoco) ├── long_url (la destinazione) ├── created_at (timestamp) ├── user_id (chi l'ha creato) └── click_count (contatore denormalizzato)

SQL (PostgreSQL, MySQL): Conformità ACID, coerenza forte, buono per scale moderate. La maggior parte degli accorciatori di URL iniziano qui.

NoSQL (DynamoDB, Cassandra): Scalabilità orizzontale migliore per miliardi di URL. La coerenza eventuale è accettabile per questo caso d'uso.

Ibrido: SQL per i mapping degli URL (è necessaria una coerenza forte per i reindirizzamenti), NoSQL o un database time-series per le analitiche dei clic (volume di scrittura elevato, la coerenza eventuale va bene).

Quando un utente fa clic su un link breve, il sistema deve:

1. 1Analizzare il codice breve dall'URL
2. 2Cercare l'URL lungo corrispondente
3. 3Restituire una risposta di reindirizzamento HTTP

• 301 (Permanente): Il browser memorizza il reindirizzamento nella cache. Meno richieste al server, ma perdi la visibilità sui clic ripetuti.
• 302 (Temporaneo): Il browser verifica con il server ogni volta. Più richieste, ma migliore tracciamento dei clic.

La maggior parte degli accorciatori di URL utilizza reindirizzamenti 302 per l'accuratezza del tracciamento dei clic, quindi offre 301 come opzione per i casi d'uso SEO. Consulta la nostra guida sui reindirizzamenti 301 per ulteriori informazioni su questa distinzione.

I reindirizzamenti devono essere veloci — ogni millisecondo di latenza influisce sull'esperienza dell'utente. Il caching è fondamentale:

Memorizza nella cache il mapping short_code → long_url in memoria:

GET /abc123 → Controlla Redis per "abc123" → Cache hit? Restituisci il reindirizzamento immediatamente → Cache miss? Interroga il database, memorizza il risultato nella cache, restituisci il reindirizzamento

Una piccola istanza Redis può memorizzare nella cache milioni di mapping di URL. Poiché la maggior parte del traffico va verso un numero relativamente piccolo di link popolari, i tassi di hit della cache superiori al 90% sono comuni.

Per i reindirizzamenti 301, i nodi edge della CDN possono memorizzare il reindirizzamento nella cache, servendo dalla posizione più vicina all'utente senza colpire affatto il tuo server di origine.

La registrazione dei dati sui clic è un'operazione con molte scritture che non dovrebbe rallentare il reindirizzamento:

1. 1L'utente fa clic sul link breve
2. 2Il sistema restituisce immediatamente il reindirizzamento
3. 3L'evento di clic viene spinto in una coda di messaggi (Kafka, RabbitMQ, SQS)
4. 4Un worker in background elabora l'evento: analizza user agent, geolocalizza IP, memorizza analitiche

Questo disaccoppia il percorso di reindirizzamento veloce dalla pipeline di analitiche più lenta.

• Timestamp
• Indirizzo IP (per la geolocalizzazione)
• User agent (per il rilevamento del dispositivo/browser)
• Intestazione referrer
• Paese, città (dalla geolocalizzazione IP)

Gli accorciatori di URL hanno un carico estremamente elevato di lettura. Un rapporto tipico potrebbe essere 100:1 letture per scritture. Questo significa:

• Ottimizzare il percorso di reindirizzamento soprattutto
• Usare il caching aggressivamente
• Leggere repliche per il database

Se usi ID auto-incrementanti su più server, è necessario evitare collisioni. Opzioni:

• Snowflake IDs: L'approccio di Twitter — incorpora timestamp, ID della macchina e numero di sequenza
• UUID: Universalmente univoco ma più lungo
• Intervalli di ID: Assegna a ogni server un intervallo di ID da allocare

Distribuisci server di reindirizzamento in più regioni. Un utente a Tokyo non dovrebbe aver bisogno di fare un round-trip verso un server in Virginia per un reindirizzamento.

Gli accorciatori di URL possono essere abusati per il phishing e la distribuzione di malware. I sistemi di produzione hanno bisogno di:

• Scansione URL — controlla le destinazioni rispetto ai database di malware e phishing
• Rate limiting — previeni la creazione massiccia di link brevi dannosi
• Segnalazione di abuso — consenti agli utenti di segnalare link sospetti
• Pagine di anteprima — mostra facoltativamente agli utenti dove va un link prima del reindirizzamento

Scopri di più sulla sicurezza dei link e protezione dal click fraud.

Oltre al shortening e al reindirizzamento di base, gli accorciatori di URL di produzione aggiungono:

• Domini personalizzati — link brevi branded usando il tuo dominio
• Slug personalizzati — scegli il tuo codice breve invece di caratteri casuali
• Scadenza — link limitati nel tempo che smettono di funzionare dopo una data
• Protezione con password — richiedi una password per accedere alla destinazione
• Test A/B — ruota tra più destinazioni
• Geotargeting — reindirizza per paese
• Targeting del dispositivo — diverse destinazioni per mobile vs. desktop
• Codici QR — genera codici scansionabili per qualsiasi link breve

La progettazione del sistema di accorciamento URL è un ottimo esercizio perché inizia semplice ma rivela strati di complessità: generazione di codici, progettazione del database, caching, pipeline di analitiche e prevenzione dell'abuso. Comprendere questi fondamentali aiuta sia che ti stia preparando per i colloqui che costruendo i tuoi strumenti.

Vuoi usare un accorciatore di URL di produzione senza costruirne uno? Inizia con Linkly — tutta l'architettura descritta sopra, pronta all'uso con domini personalizzati, analitiche e funzionalità avanzate.