Wawancara Desain Sistem: Mendesain URL Shortener

Perintah dan Cakupan

Rancang layanan yang menerima URL HTTP atau HTTPS dan mengembalikan tautan pendek. Mengunjungi tautan pendek harus mengalihkan pengguna ke tujuan yang disimpan. Desain dasar mendukung alias kustom opsional dan waktu kedaluwarsa. Analitik klik, domain kustom, manajemen akun, dan pratinjau tautan adalah tindak lanjut dan bukan persyaratan inti.

Gunakan asumsi kasus ini agar setiap klaim kapasitas dapat direproduksi:

• 1 juta tautan baru dan 100 juta pengalihan per hari;
• lalu lintas puncak mencapai 10 kali rata-rata harian;
• tautan disimpan selama lima tahun kecuali jika kedaluwarsa atau dinonaktifkan;
• jalur pengalihan menargetkan ketersediaan bulanan 99,99% dan latensi layanan p99 di bawah 100 md;
• pemetaan yang disimpan rata-rata 500 byte sebelum indeks dan replikasi.

Ini adalah asumsi wawancara, bukan pengukuran dari produk tertentu. Hal ini menyiratkan sistem yang padat membaca (read-heavy), tetapi desain harus tetap menjaga keunikan selama pembuatan bersamaan (concurrent), mengembalikan tautan yang baru dibuat secara andal setelah batas waktu yang ambigu, dan berhenti melayani tautan yang kedaluwarsa atau bersifat menyalahgunakan dalam jendela propagasi yang ditentukan.

Apa yang Dinilai Pewawancara

Sinyal pertama adalah kendali persyaratan. Jawaban yang baik memisahkan pembuatan dan pengalihan tautan dari fitur analitik dan akun, menentukan apakah tujuan dapat berubah, dan menanyakan bagaimana perilaku kedaluwarsa dan alias kustom. Menambahkan antrean, mesin pencari, atau database grafik sebelum menentukan kontrak tersebut akan melemahkan desain.

Sinyal kedua adalah apakah estimasi skala mengubah keputusan. Beban kerja yang diasumsikan rata-rata sekitar 12 pembuatan dan 1.200 pengalihan per detik, dengan puncaknya mendekati 120 dan 12.000 per detik. Lima tahun pembuatan menghasilkan sekitar 1,8 miliar pemetaan dan sekitar 0,9 TB data pemetaan mentah. Replikasi, indeks, overhead penyimpanan, dan ruang cadangan membuat jejak yang dialokasikan beberapa kali lebih besar. Angka-angka ini membenarkan penyimpanan tahan lama (durable store) yang dapat dipartisi dan cache, tetapi tidak membenarkan setiap kemungkinan komponen terdistribusi.

Sinyal ketiga adalah kebenaran pengidentifikasi. Kode Base62 delapan karakter memiliki 62^8, atau sekitar 218 triliun, kemungkinan nilai. Pada 1,8 miliar tautan yang disimpan, okupansi berada di bawah 0,001%. Oleh karena itu, pengambilan acak baru memiliki probabilitas tabrakan (collision) yang kecil, namun probabilitas bahwa sistem pernah melihat suatu tabrakan menjadi besar setelah pengambilan yang cukup banyak. Keacakan mengurangi prediktabilitas; keacakan tidak menjamin keunikan. Penulisan yang tahan lama harus secara atomik menegaskan bahwa kode tersebut tidak ada dan mencoba lagi jika terjadi tabrakan acak.

Sinyal keempat adalah penalaran jalur baca dan kegagalan. Cache adalah optimasi, bukan sumber kebenaran (source of truth). Kedaluwarsa harus diperiksa selama pembacaan alih-alih bergantung pada tugas pembersihan (cleanup job). Hot key, gangguan cache, batas waktu database, POST duplikat, lag replikasi regional, backlog analitik, dan penghapusan darurat (emergency takedown) masing-masing memerlukan perilaku yang eksplisit.

Terakhir, jawaban yang kuat memperlakukan keamanan sebagai persyaratan pengalihan inti. Tautan pendek dapat menyamarkan tujuan phishing dan kode yang dapat ditebak dapat memungkinkan enumerasi. Parsing URL, skema yang diizinkan, pembatasan laju (rate limits), pemeriksaan reputasi, pelaporan penyalahgunaan, penonaktifan cepat, dan kode publik non-sekuensial harus berada dalam desain daripada di kotak generik "tambahkan keamanan nanti".

Pertanyaan Klarifikasi Sebelum Menjawab

• Bisakah tujuan berubah setelah pembuatan? Pemetaan dasar tidak dapat diubah (immutable). Imutabilitas menyederhanakan

caching dan riwayat audit. Jika pengeditan diperlukan, tambahkan penerapan versi dan SLO pembatalan (invalidation) yang ketat.

• Haruskah URL panjang yang sama berbagi satu kode? Tidak. Pemilik, kampanye, waktu kedaluwarsa, dan

kebijakan yang berbeda mungkin memerlukan tautan yang berbeda. Deduplikasi dapat menjadi opsi eksplisit, bukan efek samping yang tidak disengaja dari pembuatan hash tujuan.

• Apakah alias kustom diperlukan? Itu bersifat opsional dan unik dalam domain yang dipilih. Konflik

akan mengembalikan 409; layanan tidak pernah mengubah alias yang diminta secara diam-diam.

• Apa yang terjadi saat kedaluwarsa? Kode yang diketahui telah kedaluwarsa atau dinonaktifkan mengembalikan 410; kode yang tidak dikenal

mengembalikan 404. Pembacaan memeriksa expires_at, sedangkan penghapusan asinkron hanya mereklamasi penyimpanan.

• Status pengalihan mana yang diharapkan? Gunakan 302 secara default karena pemetaan dapat dinonaktifkan dan

layanan mungkin memerlukan setiap permintaan untuk kebijakan atau analitik. Tawarkan 301 hanya untuk tautan yang tidak dapat diubah yang pemiliknya menerima caching klien dan perantara jangka panjang.

• Konsistensi apa yang diperlukan? Reservasi kode dan pembuatan alias kustom memerlukan keunikan

yang kuat. Pengalihan yang ada mendukung ketersediaan, tetapi pembuatan yang berhasil harus dapat dibaca segera melalui pengisian cache atau jalur read-after-write.

• Haruskah analitik bebas dari kehilangan data (lossless)? Itu berada di luar jalur dasar. Jika ditambahkan, tentukan kehilangan dan

kesegaran yang dapat diterima secara terpisah sehingga alur analitik yang tertunda tidak memblokir pengalihan.

• Apakah layanan mengambil konten tujuan? Jalur pengalihan tidak melakukannya. Pratinjau atau pemindai malware apa pun

yang mengambil URL berjalan dalam layanan asinkron terisolasi dengan pertahanan SSRF.

Kerangka Jawaban 30 Detik

"Saya akan mempertahankan pembuatan dan pengalihan sebagai dua alur inti. Dengan satu juta pembuatan dan seratus juta pengalihan per hari, rata-rata adalah sekitar 12 penulisan dan 1.200 pembacaan per detik, dengan puncak 10 kali lipat. Saya akan menghasilkan kode Base62 delapan karakter yang acak secara kriptografis dan mereservasinya dengan insert-if-absent atomik; alias kustom menggunakan kondisi yang sama. Penyimpanan pemetaan yang tahan lama dipartisi oleh hash kode dan tetap menjadi sumber kebenaran. Server pengalihan menggunakan cache-aside, memeriksa status dan kedaluwarsa, lalu mengembalikan respons 302 Location. Pembuatan bersifat idempoten, entri cache tidak pernah melebihi masa kedaluwarsa tautan, serta pembaruan atau penghapusan akan mendorong pembatalan. Saya akan menskalakan jalur baca yang panas secara independen, melindungi cache miss dari stampede, dan menjaga analitik tetap asinkron. Saya akan memvalidasi perlombaan keunikan, percobaan ulang karena respons hilang, hot key, kegagalan cache dan database, batas kedaluwarsa, dan propagasi penonaktifan penyalahgunaan terhadap SLO eksplisit."

Pembahasan Mendalam Langkah-demi-Langkah

Mulailah dengan buku besar kapasitas kecil:

Creates:   1,000,000 / 86,400 ≈ 12/s average, ≈ 120/s at 10x peak
Redirects: 100,000,000 / 86,400 ≈ 1,200/s average, ≈ 12,000/s at 10x peak
Mappings:  1,000,000 × 365 × 5 = 1.825 billion
Raw data:  1.825 billion × 500 bytes ≈ 0.9 TB before overhead and replicas
Code space: 62^8 = 218,340,105,584,896; occupancy remains below 0.001%

API inti dapat tetap sederhana:

POST /v1/links
Idempotency-Key: client-generated-key
{ "url": "https://example.com/a", "customAlias": null, "expiresAt": null }
-> 201 { "code": "aZ3kP9qR", "shortUrl": "https://sho.rt/aZ3kP9qR" }

GET /{code}
-> 302 Location: https://example.com/a
-> 404 when the code never existed
-> 410 when it is expired or disabled

Pola akses utama adalah pencarian titik (point lookup) berdasarkan kode, sehingga satu rekaman tahan lama hanya memerlukan bidang-bidang yang melayani pembuatan, pengalihan, dan kebijakan siklus hidup:

links
  code          primary key
  long_url
  owner_id
  status        ACTIVE | DISABLED
  created_at
  expires_at    nullable
  version

create_requests
  owner_id + idempotency_key    unique key
  request_fingerprint
  code
  status
  expires_at

Gunakan generator acak yang aman secara kriptografis untuk delapan karakter Base62. Ruang tujuh karakter sudah memuat sekitar 3,5 triliun nilai, tetapi karakter kedelapan memberikan lebih banyak ruang cadangan dan membuat enumerasi online lebih sulit dengan biaya URL yang dapat diabaikan. Generator acak menghindari alokator numerik terpusat dan urutan yang dapat diprediksi. Ini masih memerlukan penulisan kondisional atomik: masukkan pemetaan hanya jika code tidak ada. Jika kondisi gagal untuk kode yang dihasilkan, lakukan pengambilan acak lagi dengan jumlah percobaan ulang yang dibatasi. Jika alias kustom berkonflik, kembalikan 409 karena mengubahnya akan melanggar kontrak pemanggil.

Penghitung (counter) yang dikodekan sebagai Base62 adalah alternatif yang valid. Ini menjamin nilai kompak yang unik jika alokatornya benar, dan penyewaan rentang (range leasing) dapat mengurangi koordinasi. Biayanya adalah pemulihan alokator, kehilangan rentang, kepemilikan regional, dan enumerasi yang dapat diprediksi. Membuat hash dari URL panjang bukanlah solusi gratis: pemotongan (truncation) dapat bertabrakan, tujuan yang sama mungkin memerlukan tautan terpisah, dan menyelesaikan tabrakan masih memerlukan penyimpanan. Nyatakan properti mana yang penting sebelum memilih antara kode acak, penghitung sewaan, dan hash.

Pembuatan berlangsung dalam urutan ini:

1. Autentikasi jika diperlukan, batasi laju pemanggil (rate-limit), parsing URL, izinkan hanya http dan https,

terapkan batas panjang dan kebijakan, serta normalisasi alias kustom.

1. Periksa kunci idempoten (idempotency key). Menggunakannya kembali dengan sidik jari permintaan yang berbeda adalah konflik; menggunakannya

kembali dengan permintaan yang sama mengembalikan hasil asli.

1. Hasilkan atau terima kode. Dalam satu transaksi, reservasi kode secara kondisional dan simpan rekaman

idempoten. Transaksi ini mencegah dua pembuat memenangkan alias yang sama dan mencegah respons yang hilang menciptakan tautan yang berbeda saat dicoba lagi.

1. Setelah komit tahan lama, isi atau batalkan status cache dan antrekan pemindaian reputasi

asinkron. Jangan pernah mengembalikan kode yang hanya ada di cache.

Jika penulisan mengalami batas waktu, klien mencoba lagi dengan kunci idempoten yang sama. Layanan pertama-tama membaca rekaman permintaan dan mengembalikan hasil yang telah dikomit jika ada. Menghasilkan kode lain secara membabi buta akan mengubah respons yang ambigu menjadi status tahan lama yang duplikat. Jika penyimpanan tidak dapat membuktikan apakah transaksi telah dikomit, laporkan hasil sedang berlangsung atau dapat dicoba kembali daripada mengklaim kegagalan dan membuat pemetaan baru.

Untuk pengalihan, layanan pengalihan tepi (edge) atau stateless memeriksa daftar blokir (denylist) yang dipropagasi dengan cepat, lalu mencari code di cache terdistribusi. Kondisi hit tetap memeriksa status dan expires_at. Kondisi miss melakukan pembacaan titik dari penyimpanan tahan lama, memvalidasi bidang siklus hidup yang sama, dan menyimpan pemetaan ke dalam cache. Atur TTL cache tidak lebih lambat dari expires_at; tambahkan sedikit variasi (jitter) pada TTL umum agar banyak entri tidak kedaluwarsa secara bersamaan. Simpan kode yang tidak dikenal dalam cache secara singkat untuk menyerap pemindaian, tetapi batalkan entri negatif saat alias kustom dengan kode tersebut dibuat.

Kembalikan 302 dengan header Location secara default. Semantik HTTP mendefinisikan 302 sebagai lokasi sementara, sehingga klien terus menggunakan URL pendek pada permintaan berikutnya. 301 menunjukkan URI baru yang permanen dan dapat di-cache secara heuristik; ini dapat menghilangkan lalu lintas dari layanan tetapi juga menunda pencabutan, perubahan tujuan, dan analitik tingkat permintaan. Status pengalihan dan Cache-Control adalah kontrak produk, bukan tombol pengalih performa yang tersembunyi di dalam layanan.

Penyimpanan tahan lama dapat berupa database key-value atau database relasional yang dipartisi oleh hash dari code. Persyaratan intinya adalah create-if-absent atomik, replikasi tahan lama, point read, pencadangan (backup), dan jalur pemulihan yang teruji. Kode acak secara alami mendistribusikan lalu lintas normal, meskipun satu kode viral tetap menjadi hot key. Replikasikan cache, tambahkan cache lokal kecil untuk tautan yang sangat panas, dan gabungkan (coalesce) miss yang terjadi bersamaan sehingga satu kedaluwarsa tidak mengirimkan ribuan pembacaan identik ke database.

Kebijakan kegagalan harus mempertahankan batas sumber kebenaran:

• Jika cache tidak tersedia, gunakan circuit breaker, direct read terbatas, entri panas lokal, dan

kontrol penerimaan (admission control). Bypass cache yang tidak terbatas dapat mengubah insiden cache menjadi insiden database.

• Jika jalur baca database tidak tersedia, layani entri cache positif yang basi dan terbatas hanya jika

produk menerima risiko tersebut. Jangan pernah memperpanjang tautan yang kedaluwarsa atau melewati daftar blokir penghapusan.

• Jika jalur tulis yang tahan lama tidak dapat menjamin keunikan, gagalkan pembuatan. Ketersediaan tidak membenarkan

penerbitan dua tujuan untuk satu kode.

• Jika analitik tertunda, pengalihan terus berlanjut dan peristiwa klik di-buffer, diambil sampelnya, atau diabaikan sesuai

dengan kontrak analitik yang dinyatakan secara terpisah.

• Jika pembersihan berhenti, pembacaan tetap menegakkan kedaluwarsa. Penyimpanan bertambah, tetapi tautan kedaluwarsa tidak dilayani.

Validasi keamanan dimulai saat pembuatan dan berlanjut setelahnya. Tolak skema non-HTTP dan URL yang salah bentuk dengan parser yang sebenarnya. Batasi laju berdasarkan akun, jaringan, dan sinyal risiko; pindai tujuan secara asinkron; pertahankan alur pelaporan dan banding; serta propagasikan penghapusan yang dikonfirmasi ke jalur pengalihan dengan cepat. Kode tidak boleh memberikan akses ke konten pribadi. Jika tujuan memerlukan otorisasi, sistem tujuan harus menegakkannya; ketidakjelasan (obscurity) dalam kode pendek bukanlah kontrol akses.

Verifikasi harus menguji properti dan kegagalan. Jalankan perlombaan banyak pembuat untuk satu alias kustom dan pastikan tepat satu yang berhasil. Hilangkan respons POST pertama dan pastikan percobaan ulang idempoten mengembalikan kode yang sama. Uji satu detik sebelum, pada saat, dan setelah kedaluwarsa. Buat kode segera setelah pencarian cache negatif. Hasilkan kode acak yang cukup untuk memicu konflik kondisional secara terencana. Bebani puncak 10 kali lipat dengan set kerja yang luas dan satu kode panas, lalu gagalkan node cache, batasi database, tunda pembatalan, dan hentikan pekerja pembersihan dan analitik. Ukur keberhasilan pengalihan, latensi p99, rasio hit cache, beban miss database, konflik kondisional, penyajian tautan basi, dan propagasi penghapusan alih-alih hanya melaporkan throughput rata-rata.

Contoh Jawaban Berkualitas Tinggi

"Saya akan membatasi cakupan sistem dasar untuk membuat dan menyelesaikan tautan pendek, dengan alias kustom dan kedaluwarsa opsional. Saya akan mengklarifikasi bahwa tujuan tidak dapat diubah, URL panjang yang sama dapat menerima kode yang berbeda, tautan kedaluwarsa yang diketahui mengembalikan 410, dan analitik tidak memblokir pengalihan.

Menggunakan asumsi kasus, pembuatan rata-rata sekitar 12 permintaan per detik dan puncaknya mendekati 120; pengalihan rata-rata sekitar 1.200 dan puncaknya mendekati 12.000. Lima tahun mempertahankan sekitar 1,8 miliar pemetaan, atau sekitar 0,9 TB mentah pada 500 byte per entri. Oleh karena itu, saya akan menggunakan penyimpanan tahan lama yang mendukung point read, pemartisian, replikasi, dan insert kondisional atomik, dengan code sebagai kunci partisi.

Untuk tautan yang dihasilkan, saya akan membuat kode Base62 delapan karakter dengan keacakan kriptografis. Ruangnya adalah sekitar 218 triliun nilai, jadi peluang tabrakan per-insert tetap kecil pada skala kita, tetapi keacakan tidak membuktikan keunikan. Saya mereservasi kode dengan insert-if-absent dan mencoba lagi jika terjadi tabrakan yang dihasilkan. Konflik alias kustom mengembalikan 409. POST juga membawa kunci idempoten; pemetaan dan rekaman permintaan dikomit bersama sehingga respons yang hilang dapat mengembalikan kode yang sama.

Layanan pengalihan memeriksa daftar blokir penghapusan dan cache. Pada cache miss, layanan melakukan point read, memeriksa status aktif dan kedaluwarsa, menyimpan di cache tidak lebih lama dari sisa masa pakai, dan mengembalikan 302 dengan Location. Saya menggunakan 302 secara default karena pemetaan dapat dinonaktifkan dan layanan mungkin memerlukan kebijakan atau analitik tingkat permintaan; tautan yang tidak dapat diubah dapat memilih 301 dan caching yang lebih kuat. Entri negatif mendapatkan TTL pendek, dan membuat alias kustom membatalkan entri cache negatif apa pun.

Pemetaan yang tahan lama adalah sumber kebenaran. Kegagalan cache menurun ke pembacaan database terbatas dengan kontrol penerimaan, kegagalan database dapat menggunakan entri positif basi terbatas hanya di bawah kebijakan, dan pembuatan gagal jika keunikan tidak dapat dijamin. Hot key menggunakan caching berlapis dan penggabungan miss (miss coalescing). Analitik dan pemindaian reputasi bersifat asinkron, sedangkan penyalahgunaan yang dikonfirmasi akan menonaktifkan tautan melalui jalur kontrol yang dipropagasi dengan cepat.

Saya akan membuktikan desain ini dengan perlombaan alias bersamaan, percobaan ulang karena kehilangan respons, batas kedaluwarsa, pembatalan cache negatif, beban hot-key dan broad-set, kehilangan cache, pelambatan database, kegagalan pembersihan, dan propagasi penghapusan. Penerimaan terikat pada ketersediaan pengalihan 99,99%, p99 di bawah 100 md di bawah puncak yang dinyatakan, tidak ada pemenang kode duplikat, tidak ada tautan kedaluwarsa yang dilayani, dan jendela propagasi penonaktifan yang terukur."

Kesalahan Umum

• Membuat hash dari URL panjang dan berasumsi unik → pemotongan bertabrakan dan URL yang sama mungkin memerlukan

kebijakan terpisah → Gunakan reservasi atomik dan tentukan apakah deduplikasi diinginkan.

• Menggunakan kode acak tanpa penulisan kondisional → probabilitas disalahartikan sebagai jaminan →

Masukkan hanya jika kode tidak ada dan coba lagi tabrakan yang dihasilkan.

• Mengembalikan kode baru setelah batas waktu penulisan → satu tindakan klien membuat beberapa tautan → **Ikatkan

percobaan ulang ke kunci idempoten yang disimpan dan pulihkan hasil aslinya.**

• Menulis cache sebelum penyimpanan tahan lama → tautan yang tampak berhasil menghilang saat penggusuran (eviction) → **Komit

sumber kebenaran terlebih dahulu, lalu isi cache.**

• Bergantung pada tugas penghapusan untuk kedaluwarsa → tugas yang tertunda melayani tautan yang kedaluwarsa → **Periksa

expires_at pada setiap jalur resolusi dan gunakan pembersihan hanya untuk mereklamasi ruang.**

• Menyebut 301 "lebih cepat" dan 302 "tidak di-cache" → perilaku cache dan mutabilitas terlalu disederhanakan →

Pilih semantik pengalihan dan kontrol cache eksplisit dari kontrak produk.

• Menyimpan 404 dalam cache tanpa batas → alias kustom yang baru dibuat tetap tidak dapat dijangkau → **Gunakan

TTL negatif yang pendek dan batalkan saat pembuatan.**

• Mengirim setiap cache miss langsung ke database → kedaluwarsa hot-key menciptakan stampede → **Gunakan

penggabungan permintaan (request coalescing), jitter TTL, dan caching hot-key berlapis.**

• Membuat analitik sinkron → gangguan pada pipeline non-inti merusak pengalihan → **Keluarkan peristiwa setelah

menyelesaikan pengalihan dan tentukan kehilangan/kesegaran analitik secara terpisah.**

• Memperlakukan kode pendek sebagai otorisasi → enumerasi atau pembagian mengekspos konten yang dilindungi →

Wajibkan otorisasi di tempat tujuan dan gunakan kode hanya sebagai penunjuk lokasi (locator).

Tindak Lanjut dan Cara Menanganinya

Tindak Lanjut 1: Bagaimana Anda menambahkan analitik klik mendekati waktu nyata (near-real-time)?

Keluarkan peristiwa klik setelah keputusan pengalihan dengan code, waktu peristiwa, ID permintaan, dan hanya dimensi yang disetujui privasi. Partisi aliran berdasarkan kode untuk agregasi per tautan yang berurutan, tetapi berikan salt atau pisahkan kode yang sangat panas jika satu partisi mengalami saturasi. Konsumen memperbarui agregat menit dan harian secara idempoten. Tentukan kehilangan yang dapat diterima, duplikasi, kesegaran, retensi, penyaringan bot, dan izin sebelum memilih acknowledgement; pengalihan tidak boleh menunggu penyimpanan analitis.

Tindak Lanjut 2: Bagaimana Anda menerapkan active-active di seluruh wilayah?

Pertahankan pembacaan lokal melalui cache regional dan replika. Pembuatan kode masih memerlukan keunikan global: gunakan penyimpanan kondisional global, alokasikan namespace acak atau numerik yang terpisah per wilayah, atau rutekan pembuatan ke wilayah asal (home region). Pembuatan yang berhasil memerlukan strategi read-after-write hingga replikasi menyusul. Metadata penghapusan memerlukan jalur propagasi yang lebih cepat dan diukur secara terpisah daripada replikasi pemetaan biasa.

Tindak Lanjut 3: Apa yang berubah untuk tujuan yang dapat diedit?

Tambahkan pembaruan kondisional berversi, rekaman audit, otorisasi pemilik, dan pembatalan cache yang berkunci berdasarkan kode dan versi. Tentukan apakah respons 301 yang sudah di-cache dapat tetap basi; jika pengeditan cepat atau pencabutan penting, gunakan default 302 dengan kesegaran cache terbatas. Pembaruan bersamaan memerlukan versi yang diharapkan sehingga satu editor tidak menimpa yang lain secara diam-diam.

Tindak Lanjut 4: Bagaimana Anda menangani satu tautan yang menerima jutaan permintaan per detik?

Layani dari CDN atau edge cache, cache regional, dan cache dalam-proses (in-process) kecil, dengan pemeriksaan penghapusan yang konsisten. Replikasikan nilai panas daripada mencoba melakukan sharding pada satu kunci berdasarkan kodenya. Gabungkan penyegaran (refresh), segarkan sebelum kedaluwarsa, dan isolasi lalu lintas hot-key sehingga tidak dapat menghabiskan anggaran koneksi cache atau database secara penuh. Uji beban pembatalan karena tautan viral yang di-cache juga merupakan tautan yang paling sulit untuk dicabut dengan cepat.

Tindak Lanjut 5: Bagaimana domain kustom memengaruhi model kunci dan perutean?

Keunikan menjadi (domain, code), bukan hanya code. Verifikasi kepemilikan domain, sediakan sertifikat, rutekan berdasarkan host, serta pertahankan kuota tenant dan kebijakan penyalahgunaan. Kunci cache dan kunci partisi database harus menyertakan domain. Jika alias yang sama ada di dua domain, keduanya tidak boleh menimpa atau membatalkan satu sama lain.

Tindak Lanjut 6: Bagaimana jika penghapusan hukum harus menghapus tujuan dengan segera?

Pisahkan penonaktifan penyajian dari penghapusan fisik. Pertama tandai rekaman dinonaktifkan, perbarui daftar blokir, batalkan cache, dan verifikasi bahwa setiap wilayah mengembalikan 410 dalam SLO penghapusan. Kemudian hapus atau musnahkan secara kriptografis rekaman tahan lama, cadangan, dimensi analitik, dan salinan pencarian atau pemindai sesuai dengan kebijakan retensi. Tugas penghapusan asinkron saja tidak dapat membuktikan bahwa tautan telah berhenti dialihkan.

Tindak Lanjut 7: Bagaimana Anda bermigrasi dari delapan karakter ke kode yang lebih panjang?

Buat resolver menerima rentang panjang berversi sebelum sistem penulisan (writer) berubah. Writer baru dapat mengeluarkan kode yang lebih panjang sementara pemetaan lama terus dialihkan tanpa perubahan. Pemartisian tidak boleh bergantung pada posisi karakter tetap yang dihilangkan oleh format baru. Pantau kesalahan resolver dan parsing kunci cache, kemudian hentikan versi writer lama; jangan pernah menulis ulang kode publik yang ada hanya untuk menstandardisasi panjangnya.