<
GitHubLinkedIn
Desain sebuah Servis Short URL? Tidak Semudah yang kamu Pikir

Desain sebuah Servis Short URL? Tidak Semudah yang kamu Pikir

Rekan kerja saya membahas rencana kerjanya. Dia membutuhkan fitur untuk membuat URL singkat untuk dikirim melalui SMS. Jadi saya memberikan beberapa pertanyaan untuk mengetahui apa yang dia butuhkan.

Saya: Berapa jumlah karakter maksimum yang bisa digunakan?
A: Kami bisa menggunakan maksimal 8 karakter.

Saya: Berapa volume traffic yang diharapkan?
A: Mungkin sekitar 1 juta URL per bulan.

Saya: Apakah ada karakter khusus yang diizinkan?
A: Kami hanya menggunakan karakter base64 tanpa garis bawah (_).

Saya: Fitur apa lagi yang Anda butuhkan?
A: Kami perlu menghapus link setelah waktu kadaluwarsa.

Saya: Apakah Anda perlu menggunakan URL pendek yang sama jika mereka sudah digunakan sebelumnya?
A: Tidak, buatlah sesederhana mungkin dan kami tidak peduli tentang update atau penggunaan ulang.

Asumsi

Dari System Design Interview, kita mengetahui beberapa poin:

  • Flow process: URL Panjang --> URL Pendek --> Kadaluwarsa / dihapus.
  • Operasi tulis 1 juta data & diasumsikan dibaca 5x.
  • Diasumsikan rata-rata panjang URL adalah 50 dan kadaluwarsa 1 bulan. Persyaratan penyimpanan: 50+8 byte x 1 juta = 55 MB / bulan
  • Perlu fitur kadaluwarsa. Paling cocok adalah menggunakan fitur TTL seperti pada DynamoDB.

Desain Tingkat Tinggi

API Endpoints

  • POST /shortener (payload: long_url): untuk membuat URL pendek baru.
  • GET /{short_link}: untuk mengembalikan / mengarahkan ke URL panjang. Memerlukan kode status 302 untuk membuatnya "pindah sementara" ke URL panjang.

Apa perbedaan kode status 301 vs 302:

  • 301 membuat pindah permanen. Pada kasus ini, kamu tidak bisa menggunakan karena kamu butuh cek kadaluwarsa.
  • 302 membuat pindah sementara. Pada kasus ini, kamu bisa munggunakan untuk analisa juga & memastikan pengecekan kadaluwarsa setiap permintaan.

Ketika Anda memberikan maksimal 8 karakter, kami dapat menghitung untuk collision. Mari kita asumsikan kami menggunakan base62, 62 ^ 8 byte = 218,3 triliun probabilitas. Jika Anda hanya membutuhkan 1 juta, sudah cukup untuk mencegah collision dan mengembangkan sistem.

Menggunakan fungsi TTL DynamoDB, ini akan membantu membersihkan secara otomatis. Setelah waktu yang ditentukan berlalu, itu akan dihapus.

Asumsi Biaya

Mari kita hitung lagi, kita menggunakan semua produk AWS & mengoptimalkan biaya tanpa paket gratis:

  1. AWS Lambda, dengan RAM 128MB, asumsi 50ms/ requests
  2. AWS API Gateway, menggunakan HTTP APIs, asumsi network keluar 1KB
  3. AWS Route53, standar
  4. AWS DynamoDB, kapasitas on-demand
Komponen Formula Harga
Lambda - Requests 6,000,000req / 1,000,000 x $0.2 $1.20
Lambda - CPU 6,000,000req x 128MB / 1024 x 50ms / 1000 x $0.000016 $0.60
API Gateway - Requests 6,000,000req / 1,000,000 x $1.25 $7.50
API Gateway - Network 6,000,000req x 1 KB / 1024 / 1024 x $0.09 $0.51
Route53 - Hosted Zone 1 x $0.5 $0.50
Route53 - Queries 6,000,000req / 1,000,000 x $0.4 $2.40
DynamoDB - Write WRU 1,000,000req / 1,000,000 x $1.42 $1.42
DynamoDB - Read RRU 6,000,000req / 1,000,000 x $0.29 $1.74
DynamoDB - Storage 1,000,000req x 1KB / 1024 / 1024 x $0.29 $0.28
DynamoDB - Network 5,000,000req x 1KB / 1024 / 1024 x $0.12 $0.57
Total $16.72