Desain Sistem URL Shortener: Cara Kerja Link Shortener di Balik Layar

"Desain URL shortener" adalah salah satu pertanyaan desain sistem wawancara paling populer — dan ada alasan yang bagus untuk itu. Ini menyentuh hashing, database, caching, load balancing, dan sistem terdistribusi, semuanya dalam produk yang tampak sederhana.

Dalam panduan ini, kami akan membahas cara URL shortener sebenarnya bekerja, keputusan desain kunci, dan trade-off yang terlibat dalam skala besar.

Alur Dasar

URL shortener melakukan dua hal:

1
Shorten: Ambil URL panjang dan buat kode pendek
2
Redirect: Ketika seseorang mengunjungi URL pendek, arahkan mereka ke URL asli

Berikut alur tingkat tingginya:

Pengguna membuat link pendek:
  URL panjang → Buat kode pendek → Simpan mapping → Kembalikan URL pendek

Pengguna klik link pendek:
  URL pendek → Cari kode → Temukan URL panjang → 301 Redirect

Membuat Kode Pendek

Tantangan inti adalah membuat kode unik yang pendek. Ada beberapa pendekatan:

Pendekatan 1: Encoding Base62

Ubah ID yang auto-increment menjadi string Base62 menggunakan karakter [a-zA-Z0-9]:

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

Kode Base62 7-karakter mendukung 62^7 = 3,5 triliun URL unik.

Kelebihan: Sederhana, panjang dapat diprediksi, tanpa collision Kekurangan: ID sekuensial dapat diprediksi (pengguna dapat menebak URL pendek lainnya)

Pendekatan 2: Hashing

Terapkan fungsi hash (MD5, SHA-256) ke URL panjang dan ambil N karakter pertama:

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

Kelebihan: Input yang sama selalu menghasilkan output yang sama (deduplication) Kekurangan: Hash collision memerlukan penanganan; panjang hash tetap mungkin membuang ruang

Pendekatan 3: Random Generation

Buat string alfanumerik acak dan periksa keunikan:

Kelebihan: Sederhana, tidak dapat diprediksi Kekurangan: Memerlukan pemeriksaan collision pada setiap pembuatan; menjadi lebih lambat saat database penuh

Pendekatan Mana yang Digunakan?

Sebagian besar sistem produksi menggunakan encoding Base62 dengan ID generator terdistribusi. Ini sederhana, bebas collision, dan performan. Di Linkly, kami menggunakan pendekatan serupa — Anda dapat membaca lebih lanjut tentang cara kerja URL shortener untuk ikhtisar yang kurang teknis.

Desain Database

Tabel inti cukup straightforward:

urls ├── id (primary key, auto-increment) ├── short_code (unique index) ├── long_url (destination) ├── created_at (timestamp) ├── user_id (siapa yang membuatnya) └── click_count (denormalized counter)

SQL vs. NoSQL

SQL (PostgreSQL, MySQL): ACID compliance, strong consistency, baik untuk skala sedang. Sebagian besar URL shortener dimulai di sini.

NoSQL (DynamoDB, Cassandra): Scaling horizontal yang lebih baik untuk miliaran URL. Eventual consistency dapat diterima untuk use case ini.

Hybrid: SQL untuk URL mappings (membutuhkan strong consistency untuk redirect), NoSQL atau time-series database untuk click analytics (volume write tinggi, eventual consistency baik-baik saja).

Menangani Redirect

Ketika pengguna mengklik link pendek, sistem harus:

1
Parse kode pendek dari URL
2
Cari URL panjang yang sesuai
3
Kembalikan respons HTTP redirect

301 vs. 302 Redirect

301 (Permanent): Browser cache redirect. Lebih sedikit permintaan server, tetapi Anda kehilangan visibilitas ke clicks berulang.
302 (Temporary): Browser memeriksa dengan server setiap kali. Lebih banyak permintaan, tetapi tracking click lebih baik.

Sebagian besar URL shortener menggunakan 302 redirect untuk akurasi click tracking, kemudian menawarkan 301 sebagai opsi untuk use case SEO. Lihat panduan kami tentang 301 redirect untuk lebih lanjut tentang perbedaan ini.

Caching

Redirect perlu cepat — setiap milidetik latency mempengaruhi pengalaman pengguna. Caching adalah kritis:

In-Memory Cache (Redis/Memcached)

Cache mapping short_code → long_url di memory:

GET /abc123 → Cek Redis untuk "abc123" → Cache hit? Kembalikan redirect langsung → Cache miss? Query database, cache result, kembalikan redirect

Instansi Redis kecil dapat cache jutaan URL mapping. Karena sebagian besar traffic masuk ke jumlah link populer yang relatif kecil, cache hit rate di atas 90% adalah umum.

CDN Caching

Untuk 301 redirect, edge node CDN dapat cache respons redirect, melayaninya dari lokasi terdekat ke pengguna tanpa mengenai origin server Anda sama sekali.

Analytics dan Click Tracking

Merekam data click adalah operasi write-heavy yang tidak seharusnya memperlambat redirect:

Asynchronous Processing

1
Pengguna klik short link
2
Sistem langsung mengembalikan redirect
3
Click event didorong ke message queue (Kafka, RabbitMQ, SQS)
4
Background worker memproses event: parse user agent, geolocate IP, store analytics

Ini memisahkan fast redirect path dari analytics pipeline yang lebih lambat.

Data untuk Ditangkap

Timestamp
IP address (untuk geolocation)
User agent (untuk device/browser detection)
Referrer header
Negara, kota (dari IP geolocation)

Scaling Considerations

Read-Heavy Workload

URL shortener sangat read-heavy. Rasio khas mungkin 100:1 reads ke writes. Ini berarti:

Optimalkan redirect path di atas segalanya
Gunakan caching secara agresif
Read replicas untuk database

Distributed ID Generation

Jika Anda menggunakan ID auto-increment di beberapa server, Anda perlu menghindari collision. Opsi:

Snowflake IDs: Pendekatan Twitter — embed timestamp, machine ID, dan sequence number
UUID: Universally unique tetapi lebih panjang
ID ranges: Tetapkan setiap server rentang ID untuk dialokasikan

Geographic Distribution

Deploy redirect server di beberapa region. Pengguna di Tokyo tidak seharusnya perlu round-trip ke server di Virginia untuk redirect.

Pertimbangan Keamanan

URL shortener dapat disalahgunakan untuk phishing dan distribusi malware. Sistem produksi memerlukan:

URL scanning — periksa destination terhadap malware dan phishing database
Rate limiting — cegah pembuatan massal short link berbahaya
Abuse reporting — biarkan pengguna melaporkan link mencurigakan
Preview pages — secara opsional tunjukkan kepada pengguna ke mana link menuju sebelum redirect

Pelajari lebih lanjut tentang link safety dan click fraud protection.

Fitur Tambahan

Melampaui shortening dan redirecting dasar, URL shortener produksi menambahkan:

Custom domains — branded short link menggunakan domain Anda sendiri
Custom slugs — pilih kode pendek Anda sendiri daripada karakter acak
Expiration — time-limited link yang berhenti bekerja setelah tanggal
Password protection — memerlukan password untuk mengakses destination
A/B testing — rotate antara beberapa destination
Geo-targeting — redirect berdasarkan negara
Device targeting — destination berbeda untuk mobile vs. desktop
QR codes — buat kode scannable untuk short link apa pun

Kesimpulan

Desain sistem URL shortener adalah latihan yang bagus karena dimulai sederhana tetapi mengungkap lapisan kompleksitas: code generation, desain database, caching, analytics pipeline, dan abuse prevention. Memahami fundamentals ini membantu baik Anda bersiap untuk wawancara atau membangun tools Anda sendiri.

Ingin menggunakan URL shortener produksi tanpa membangun sendiri? Mulai dengan Linkly — semua arsitektur yang dijelaskan di atas, siap digunakan dengan custom domain, analytics, dan fitur advanced.