Temu Duga Reka Bentuk Sistem: Mereka Bentuk Pemendek URL (URL Shortener)

Prompt dan Skop

Reka bentuk perkhidmatan yang menerima URL HTTP atau HTTPS dan mengembalikan pautan pendek. Melawati pautan pendek tersebut mesti menghala semula pengguna ke destinasi yang disimpan. Reka bentuk asas menyokong alias tersuai pilihan dan masa tamat tempoh. Analitis klik, domain tersuai, pengurusan akaun, dan pratonton pautan adalah perkara susulan dan bukannya keperluan teras.

Gunakan andaian kes ini supaya setiap tuntutan kapasiti boleh dihasilkan semula:

• 1 juta pautan baharu dan 100 juta penghalaan semula setiap hari;
• trafik memuncak pada 10 kali ganda purata harian;
• pautan disimpan selama lima tahun melainkan ia tamat tempoh atau dinyahdayakan;
• laluan penghalaan semula menyasarkan ketersediaan bulanan 99.99% dan pendaman perkhidmatan p99 di bawah 100 ms;
• pemetaan yang disimpan berpurata 500 bait sebelum indeks dan replikasi.

Ini adalah andaian temu duga, bukan pengukuran daripada produk yang dinamakan. Ia membayangkan sistem yang berat membaca (read-heavy), tetapi reka bentuk mesti tetap mengekalkan keunikan semasa penciptaan serentak, mengembalikan pautan yang baru dicipta dengan andal selepas tamat masa yang kabur (ambiguous timeouts), dan berhenti menyajikan pautan yang telah tamat tempoh atau digunakan untuk penyalahgunaan dalam tetingkap penyebaran yang ditetapkan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah kawalan keperluan. Jawapan yang berguna memisahkan penciptaan pautan dan penghalaan semula daripada ciri analitis dan akaun, mentakrifkan sama ada destinasi boleh berubah, dan bertanyakan cara tamat tempoh dan alias tersuai bertindak. Menambah baris gilir, enjin carian, atau pangkalan data graf sebelum mentakrifkan kontrak tersebut melemahkan reka bentuk.

Isyarat kedua ialah sama ada anggaran skala mengubah keputusan. Beban kerja yang diandaikan berpurata kira-kira 12 penciptaan dan 1,200 penghalaan semula sesaat, dengan puncak hampir 120 dan 12,000 sesaat. Lima tahun penciptaan menghasilkan kira-kira 1.8 bilion pemetaan dan kira-kira 0.9 TB data pemetaan mentah. Replikasi, indeks, overhed storan, dan margin kapasiti (headroom) menjadikan jejak yang diperuntukkan beberapa kali lebih besar. Angka-angka ini mewajarkan stor tahan lama yang boleh dipisahkan (partitionable) dan cache, tetapi ia tidak mewajarkan setiap komponen teragih yang mungkin.

Isyarat ketiga ialah ketepatan pengecam. Kod Base62 lapan aksara mempunyai 62^8, atau kira-kira 218 trilion, nilai yang mungkin. Pada 1.8 bilion pautan yang disimpan, penghunian adalah di bawah 0.001%. Oleh itu, cabutan rawak baharu mempunyai kebarangkalian perlanggaran yang kecil, namun kebarangkalian bahawa sistem pernah melihat beberapa perlanggaran menjadi besar selepas cabutan yang mencukupi. Kerawakan mengurangkan kebolehramalan; ia tidak menjamin keunikan. Penulisan tahan lama mesti menegaskan secara atomik bahawa kod itu tidak wujud dan mencuba semula sekiranya berlaku perlanggaran rawak.

Isyarat keempat ialah laluan bacaan dan penaakulan kegagalan. Cache ialah pengoptimuman, bukan sumber kebenaran (source of truth). Tamat tempoh mesti diperiksa semasa bacaan dan bukannya bergantung pada tugas pembersihan. Kunci hangat (hot key), gangguan cache, tamat masa pangkalan data, POST pendua, kelengahan replikasi serantau, tunggakan analitis, dan penutupan kecemasan (emergency takedown) masing-masing memerlukan tingkah laku yang eksplisit.

Akhir sekali, jawapan yang kukuh menganggap keselamatan sebagai keperluan teras penghalaan semula. Pautan pendek boleh menyamarkan destinasi pemancingan data (phishing) dan kod yang boleh diramal boleh membolehkan penghitungan (enumeration). Penghuraian URL, skema yang dibenarkan, had kadar, semakan reputasi, pelaporan penyalahgunaan, pelumpuhan pantas, dan kod awam bukan berjujukan tergolong dalam reka bentuk dan bukannya dalam kotak generik “tambah keselamatan kemudian”.

Soalan Penjelasan Sebelum Menjawab

• Bolehkah destinasi berubah selepas penciptaan? Pemetaan asas tidak boleh diubah (immutable). Ketakbolehubahan memudahkan

penyimpanan cache dan sejarah audit. Jika pengeditan diperlukan, tambah pemversian dan SLO pembatalan yang ketat.

• Patutkah URL panjang yang sama berkongsi satu kod? Tidak. Pemilik, kempen, masa tamat tempoh, dan

dasar yang berbeza mungkin memerlukan pautan yang berbeza. Nyahpenduaan boleh menjadi pilihan yang eksplisit, bukan kesan sampingan yang tidak disengajakan daripada pencincangan destinasi.

• Adakah alias tersuai diperlukan? Ia adalah pilihan dan unik dalam domain yang dipilih. Konflik

mengembalikan 409; perkhidmatan tidak sekali-kali mengubah alias yang diminta secara senyap.

• Apakah yang berlaku apabila tamat tempoh? Kod tamat tempoh atau dinyahdayakan yang diketahui mengembalikan 410; kod yang tidak diketahui

mengembalikan 404. Bacaan memeriksa expires_at, manakala pemadaman tak segerak hanya menuntut semula storan.

• Status penghalaan semula yang manakah dijangkakan? Gunakan 302 secara lalai kerana pemetaan mungkin dinyahdayakan dan

perkhidmatan mungkin memerlukan setiap permintaan untuk dasar atau analitis. Tawarkan 301 hanya untuk pautan tidak boleh ubah yang pemiliknya menerima penyimpanan cache klien dan perantara yang tahan lama.

• Apakah ketekalan yang diperlukan? Tempahan kod dan penciptaan alias tersuai memerlukan keunikan

yang kuat. Penghalaan semula sedia ada mengutamakan ketersediaan, tetapi penciptaan yang berjaya mesti boleh dibaca serta-merta melalui pengisian cache atau laluan baca-selepas-tulis (read-after-write).

• Adakah analitis mesti tanpa kehilangan (lossless)? Ia berada di luar laluan asas. Jika ditambah, takrifkan kehilangan dan

kesegaran yang boleh diterima secara berasingan supaya talian paip analitis yang tertangguh tidak menyekat penghalaan semula.

• Adakah perkhidmatan mengambil kandungan destinasi? Laluan penghalaan semula tidak melakukannya. Sebarang pratonton atau pengimbas

perisian hasad yang mengambil URL berjalan dalam perkhidmatan tak segerak terpencil dengan pertahanan SSRF.

Rangka Kerja Jawapan 30 Saat

“Saya akan mengekalkan penciptaan dan penghalaan semula sebagai dua aliran teras. Dengan satu juta penciptaan dan seratus juta penghalaan semula setiap hari, purata ialah kira-kira 12 penulisan dan 1,200 bacaan sesaat, dengan puncak 10 kali ganda. Saya akan menjana kod Base62 lapan aksara rawak secara kriptografi dan menempahnya dengan sisipan-jika-tiada (insert-if-absent) secara atomik; alias tersuai menggunakan syarat yang sama. Stor pemetaan tahan lama dipisahkan mengikut cincangan kod dan kekal sebagai sumber kebenaran. Pelayan penghalaan semula menggunakan cache-aside, memeriksa status dan tamat tempoh, kemudian mengembalikan respons 302 Location. Penciptaan adalah idempoten, entri cache tidak pernah hidup lebih lama daripada tamat tempoh pautan, dan kemas kini atau penyingkiran menolak pembatalan. Saya akan menskalakan laluan bacaan hangat secara bebas, melindungi miss cache daripada rempuhan (stampedes), dan memastikan analitis kekal tak segerak. Saya akan mengesahkan perlumbaan keunikan, percubaan semula kehilangan respons, kunci hangat, kegagalan cache dan pangkalan data, sempadan tamat tempoh, dan penyebaran pelumpuhan penyalahgunaan terhadap SLO yang eksplisit.”

Pendalaman Langkah demi Langkah

Mulakan dengan lejar kapasiti 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 teras boleh kekal sempit:

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

Corak akses utama ialah carian titik mengikut kod, jadi satu rekod tahan lama hanya memerlukan medan yang melayani penciptaan, penghalaan semula, dan dasar kitaran hayat:

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 penjana rawak yang selamat secara kriptografi untuk lapan aksara Base62. Ruang tujuh aksara sudah mengandungi kira-kira 3.5 trilion nilai, tetapi aksara kelapan memberikan margin kapasiti yang lebih besar dan menjadikan penghitungan dalam talian lebih sukar pada kos URL yang boleh diabaikan. Penjana rawak mengelakkan penguntuk angka berpusat dan jujukan yang boleh diramal. Ia masih memerlukan penulisan bersyarat atomik: masukkan pemetaan hanya jika code tiada. Jika syarat gagal untuk kod yang dijana, cabut semula dengan kiraan percubaan semula yang terhad. Jika alias tersuai berkonflik, kembalikan 409 kerana mengubahnya akan melanggar kontrak pemanggil.

Kaunter yang dikodkan sebagai Base62 ialah alternatif yang sah. Ia menjamin nilai padat yang unik jika penguntuk adalah betul, dan pemajakan julat boleh mengurangkan penyelarasan. Kosnya ialah pemulihan penguntuk, kehilangan julat, pemilikan serantau, dan penghitungan yang boleh diramal. Mencincang URL panjang bukanlah penyelesaian percuma: pemotongan boleh berlanggar, destinasi yang sama mungkin memerlukan pautan berasingan, dan menyelesaikan perlanggaran masih memerlukan storan. Nyatakan sifat yang penting sebelum memilih antara kod rawak, kaunter dipajak, dan cincangan.

Penciptaan diteruskan dalam susunan ini:

1. Sahkan pengesahan jika diperlukan, hadkan kadar pemanggil, huraikan URL, benarkan hanya http dan https,

kuat kuasakan had panjang dan dasar, dan normalkan alias tersuai.

1. Periksa kunci keidempotenan. Menggunakannya semula dengan cap jari permintaan yang berbeza ialah konflik; menggunakannya

semula dengan permintaan yang sama mengembalikan hasil asal.

1. Jana atau terima kod. Dalam satu transaksi, tempah kod secara bersyarat dan simpan rekod

keidempotenan. Transaksi menghalang dua pencipta daripada memenangi alias yang sama dan menghalang respons yang hilang daripada mencipta pautan berbeza semasa percubaan semula.

1. Selepas komit tahan lama, isi atau batalkan keadaan cache dan masukkan pengimbasan reputasi

tak segerak ke dalam baris gilir. Jangan sekali-kali mengembalikan kod yang wujud hanya dalam cache.

Jika penulisan tamat masa, klien mencuba semula dengan kunci keidempotenan yang sama. Perkhidmatan terlebih dahulu membaca rekod permintaan dan mengembalikan hasil yang dikomit jika ada. Menjana kod lain secara membuta tuli menjadikan respons yang kabur sebagai keadaan tahan lama pendua. Jika stor tidak dapat membuktikan sama ada transaksi telah dikomit, laporkan hasil yang sedang berjalan atau boleh dicuba semula daripada mendakwa kegagalan dan mencipta pemetaan baharu.

Untuk penghalaan semula, perkhidmatan penghalaan semula pinggir atau tanpa keadaan (stateless) memeriksa senarai penafian (denylist) yang disebarkan dengan pantas, kemudian mencari code dalam cache teragih. Hit masih memeriksa status dan expires_at. Miss melakukan bacaan titik daripada stor tahan lama, mengesahkan medan kitaran hayat yang sama, dan mencache pemetaan. Tetapkan TTL cache selewat-lewatnya expires_at; tambah sedikit jitter pada TTL yang luas supaya banyak entri tidak tamat tempoh bersama-sama. Cache kod yang tidak diketahui secara ringkas untuk menyerap imbasan, tetapi batalkan entri negatif apabila alias tersuai dengan kod tersebut dicipta.

Kembalikan 302 dengan pengepala Location secara lalai. Semantik HTTP mentakrifkan 302 sebagai lokasi sementara, jadi klien terus menggunakan URL pendek pada permintaan masa hadapan. 301 menunjukkan URI baharu yang kekal dan boleh dicache secara heuristik; ia boleh mengalihkan trafik daripada perkhidmatan tetapi juga melengahkan pembatalan, perubahan destinasi, dan analitis peringkat permintaan. Status penghalaan semula dan Cache-Control ialah kontrak produk, bukan togol prestasi yang tersembunyi di dalam perkhidmatan.

Stor tahan lama boleh menjadi pangkalan data nilai-kunci atau pangkalan data hubungan yang dipisahkan mengikut cincangan code. Keperluan teras ialah cipta-jika-tiada secara atomik, replikasi tahan lama, bacaan titik, sandaran, dan laluan pemulihan yang diuji. Kod rawak secara semula jadi mengedarkan trafik normal, walaupun satu kod tular masih merupakan kunci hangat. Replikasi cache, tambah cache tempatan kecil untuk pautan yang sangat hangat, dan gabungkan (coalesce) miss serentak supaya satu tamat tempoh tidak menghantar ribuan bacaan yang sama ke pangkalan data.

Dasar kegagalan mesti mengekalkan sempadan sumber kebenaran:

• Jika cache tidak tersedia, gunakan pemutus litar (circuit breaker), bacaan langsung yang terhad, entri hangat tempatan, dan

kawalan kemasukan (admission control). Pintasan cache tanpa had boleh menjadikan insiden cache sebagai insiden pangkalan data.

• Jika laluan bacaan pangkalan data tidak tersedia, sajikan entri cache positif basi yang terhad hanya apabila

produk menerima risiko tersebut. Jangan sekali-kali melanjutkan pautan yang telah tamat tempoh atau memintas senarai penafian penyingkiran.

• Jika laluan penulisan tahan lama tidak dapat menjamin keunikan, gagalkan penciptaan. Ketersediaan tidak mewajarkan

pengeluaran dua destinasi untuk satu kod.

• Jika analitis tertangguh, penghalaan semula diteruskan dan peristiwa klik ditimbal, disampel, atau digugurkan mengikut

kontrak analitis yang dinyatakan secara berasingan.

• Jika pembersihan berhenti, bacaan masih menguatkuasakan tamat tempoh. Storan berkembang, tetapi pautan tamat tempoh tidak disajikan.

Pengesahan keselamatan bermula semasa penciptaan dan berterusan selepasnya. Tolak skema bukan HTTP dan URL yang tidak betul bentuk dengan penghurai sebenar. Hadkan kadar mengikut akaun, rangkaian, dan isyarat risiko; imbas destinasi secara tak segerak; kekalkan aliran pelaporan dan rayuan; dan sebarkan penyingkiran yang disahkan ke laluan penghalaan semula dengan cepat. Kod tidak seharusnya memberikan akses kepada kandungan peribadi. Jika destinasi memerlukan kebenaran, sistem destinasi mesti menguatkuasakannya; kekaburan dalam kod pendek bukanlah kawalan akses.

Pengesahan harus menguji sifat dan kegagalan. Perlumbakan ramai pencipta untuk satu alias tersuai dan sahkan tepat satu yang berjaya. Hilangkan respons POST pertama dan sahkan percubaan semula idempoten mengembalikan kod yang sama. Uji satu saat sebelum, pada, dan selepas tamat tempoh. Cipta kod serta-merta selepas carian cache negatif. Jana kod rawak yang mencukupi untuk menguji konflik bersyarat secara buatan. Muatkan puncak 10 kali ganda dengan kedua-dua set kerja yang luas dan satu kod hangat, kemudian gagalkan nod cache, sekat pangkalan data, lengahkan pembatalan, dan hentikan pekerja pembersihan dan analitis. Ukur kejayaan penghalaan semula, pendaman p99, kadar hit cache, beban miss pangkalan data, konflik bersyarat, penyajian pautan basi, dan penyebaran penyingkiran daripada hanya melaporkan daya pemprosesan purata.

Contoh Jawapan Berkualiti Tinggi

“Saya akan menghadkan skop sistem asas untuk mencipta dan menyelesaikan pautan pendek, dengan pilihan alias tersuai dan tamat tempoh. Saya akan menjelaskan bahawa destinasi tidak boleh diubah, URL panjang yang sama mungkin menerima kod yang berbeza, pautan tamat tempoh yang diketahui mengembalikan 410, dan analitis tidak menyekat penghalaan semula.

Menggunakan andaian kes, penciptaan berpurata kira-kira 12 permintaan sesaat dan memuncak hampir 120; penghalaan semula berpurata kira-kira 1,200 dan memuncak hampir 12,000. Lima tahun mengekalkan kira-kira 1.8 bilion pemetaan, atau kira-kira 0.9 TB mentah pada 500 bait setiap satu. Oleh itu, saya akan menggunakan stor tahan lama yang menyokong bacaan titik, pemisahan, replikasi, dan sisipan bersyarat atomik, dengan code sebagai kunci pemisahan.

Untuk pautan yang dijana, saya akan mencabut kod Base62 lapan aksara dengan kerawakan kriptografi. Ruang tersebut adalah kira-kira 218 trilion nilai, jadi peluang perlanggaran setiap sisipan kekal kecil pada skala kita, tetapi kerawakan tidak membuktikan keunikan. Saya menempah kod dengan sisipan-jika-tiada dan mencuba semula perlanggaran yang dijana. Konflik alias tersuai mengembalikan 409. POST juga membawa kunci keidempotenan; pemetaan dan rekod permintaan dikomit bersama-sama supaya respons yang hilang boleh mengembalikan kod yang sama.

Perkhidmatan penghalaan semula memeriksa senarai penafian penyingkiran dan cache. Pada miss cache, ia melakukan bacaan titik, memeriksa status aktif dan tamat tempoh, mencache tidak lebih lama daripada baki jangka hayat, dan mengembalikan 302 dengan Location. Saya menggunakan 302 secara lalai kerana pemetaan mungkin dinyahdayakan dan perkhidmatan mungkin memerlukan dasar atau analitis peringkat permintaan; pautan tidak boleh ubah boleh memilih 301 dan penyimpanan cache yang lebih kuat. Entri negatif mendapat TTL pendek, dan mencipta alias tersuai membatalkan sebarang entri cache negatif.

Pemetaan tahan lama ialah sumber kebenaran. Kegagalan cache menurun kepada bacaan pangkalan data terhad dengan kawalan kemasukan, kegagalan pangkalan data boleh menggunakan entri positif basi yang terhad hanya di bawah dasar, dan penciptaan gagal jika keunikan tidak dapat dijamin. Kunci hangat menggunakan cache berlapis dan penggabungan miss (miss coalescing). Analitis dan pengimbasan reputasi adalah tak segerak, manakala penyalahgunaan yang disahkan melumpuhkan pautan melalui laluan kawalan yang disebarkan dengan pantas.

Saya akan membuktikan reka bentuk dengan perlumbaan alias serentak, percubaan semula kehilangan respons, sempadan tamat tempoh, pembatalan cache negatif, beban kunci hangat dan set luas, kehilangan cache, pendikit pangkalan data, kegagalan pembersihan, dan penyebaran penyingkiran. Penerimaan terikat kepada ketersediaan penghalaan semula 99.99%, p99 di bawah 100 ms di bawah puncak yang dinyatakan, tiada pemenang kod pendua, tiada pautan tamat tempoh yang disajikan, dan tetingkap penyebaran pelumpuhan yang diukur.”

Kesilapan Biasa

• Mencincang URL panjang dan menganggap keunikan → pemotongan berlanggar dan URL yang sama mungkin memerlukan

dasar yang berasingan → Gunakan tempahan atomik dan tentukan sama ada nyahpenduaan dikehendaki.

• Menggunakan kod rawak tanpa penulisan bersyarat → kebarangkalian disalah anggap sebagai jaminan →

Masukkan hanya apabila kod tiada dan cuba semula perlanggaran yang dijana.

• Mengembalikan kod baharu selepas tamat masa penulisan → satu tindakan klien mencipta berbilang pautan → **Ikat

percubaan semula pada kunci keidempotenan yang disimpan dan pulihkan hasil asal.**

• Menulis cache sebelum storan tahan lama → pautan yang kelihatan berjaya hilang apabila disingkirkan (eviction) → **Komit

sumber kebenaran terlebih dahulu, kemudian isi cache.**

• Bergantung pada tugas pemadaman untuk tamat tempoh → tugas yang tertangguh menyajikan pautan yang telah tamat tempoh → **Periksa

expires_at pada setiap laluan penyelesaian dan gunakan pembersihan hanya untuk menuntut semula ruang.**

• Memanggil 301 “lebih pantas” dan 302 “tidak dicache” → tingkah laku cache dan kebolehubahan dipermudahkan secara keterlaluan →

Pilih semantik penghalaan semula dan kawalan cache eksplisit daripada kontrak produk.

• Mencache 404 selama-lamanya → alias tersuai yang baru dicipta kekal tidak dapat dicapai → **Gunakan TTL negatif

yang pendek dan batalkannya semasa penciptaan.**

• Menghantar setiap miss cache terus ke pangkalan data → tamat tempoh kunci hangat mencipta rempuhan → **Gunakan

penggabungan permintaan, jitter TTL, dan penyimpanan cache kunci hangat berlapis.**

• Menjadikan analitis segerak → gangguan talian paip bukan teras merosakkan penghalaan semula → **Pancarkan peristiwa selepas

menyelesaikan dan tentukan kehilangan/kesegaran analitis secara berasingan.**

• Menganggap kod pendek sebagai kebenaran (authorization) → penghitungan atau perkongsian mendedahkan kandungan yang dilindungi →

Wajibkan kebenaran di destinasi dan gunakan kod hanya sebagai pencari (locator).

Soalan Susulan dan Cara Mengendalikannya

Susulan 1: Bagaimanakah anda menambah analitis klik hampir masa nyata?

Pancarkan peristiwa klik selepas keputusan penghalaan semula dengan code, masa peristiwa, ID permintaan, dan hanya dimensi yang diluluskan privasi. Pisahkan aliran mengikut kod untuk agregasi setiap pautan yang teratur, tetapi garamkan (salt) atau pisahkan kod yang sangat hangat jika satu partition tepu. Pengguna mengemas kini agregat minit dan harian secara idempoten. Takrifkan kehilangan, penduaan, kesegaran, pengekalan, penapisan bot, dan persetujuan yang boleh diterima sebelum memilih perakuan (acknowledgements); penghalaan semula tidak boleh menunggu stor analisis.

Susulan 2: Bagaimanakah anda menggunakan aktif-aktif merentas wilayah?

Kekalkan bacaan secara tempatan melalui cache dan replika serantau. Penciptaan kod masih memerlukan keunikan global: gunakan stor bersyarat secara global, peruntukkan ruang nama rawak atau angka yang tidak bertindih bagi setiap wilayah, atau halakan penciptaan ke wilayah asal. Penciptaan yang berjaya memerlukan strategi baca-selepas-tulis sehingga replikasi selesai. Metadata penyingkiran memerlukan laluan penyebaran yang lebih pantas dan diukur secara berasingan daripada replikasi pemetaan biasa.

Susulan 3: Apakah perubahan untuk destinasi yang boleh diedit?

Tambah kemas kini bersyarat berversi, rekod audit, kebenaran pemilik, dan pembatalan cache yang berkunci mengikut kod dan versi. Takrifkan sama ada respons 301 yang telah dicache boleh kekal basi; jika pengeditan pantas atau pembatalan penting, jadikan 302 sebagai lalai dengan kesegaran cache yang terhad. Kemas kini serentak memerlukan versi yang dijangkakan supaya seorang editor tidak menulis ganti yang lain secara senyap.

Susulan 4: Bagaimanakah anda mengendalikan satu pautan yang menerima jutaan permintaan sesaat?

Sajikan ia daripada CDN atau cache pinggir, cache serantau, dan cache dalam-proses yang kecil, dengan semakan penyingkiran yang tekal. Replikasi nilai hangat dan bukannya cuba membahagikan (shard) satu kunci mengikut kodnya. Gabungkan penyegaran, segar semula sebelum tamat tempoh, dan asingkan trafik kunci hangat supaya ia tidak dapat menggunakan belanjawan sambungan cache atau pangkalan data penuh. Uji beban pembatalan kerana pautan tular yang dicache juga merupakan pautan paling sukar untuk dibatalkan dengan cepat.

Susulan 5: Bagaimanakah domain tersuai mempengaruhi model kunci dan penghalaan?

Keunikan menjadi (domain, code), bukan hanya code. Sahkan pemilikan domain, peruntukkan sijil, halakan mengikut hos, dan kekalkan kuota penyewa serta dasar penyalahgunaan. Kunci cache dan kunci pemisahan pangkalan data mesti menyertakan domain. Jika alias yang sama wujud pada dua domain, kedua-duanya tidak boleh menulis ganti atau membatalkan antara satu sama lain.

Susulan 6: Bagaimana jika pemadaman undang-undang mesti memadamkan destinasi serta-merta?

Asingkan pelumpuhan penyajian daripada pemadaman fizikal. Mula-mula tandakan rekod dinyahdayakan, kemas kini senarai penafian, batalkan cache, dan sahkan bahawa setiap wilayah mengembalikan 410 dalam SLO penyingkiran. Kemudian padam atau padam secara kriptografi rekod tahan lama, sandaran, dimensi analitis, dan salinan carian atau pengimbas mengikut dasar pengekalan. Tugas pemadaman tak segerak sahaja tidak dapat membuktikan bahawa pautan itu telah berhenti diselesaikan.

Susulan 7: Bagaimanakah anda berhijrah daripada kod lapan aksara kepada kod yang lebih panjang?

Jadikan penyelesai (resolver) menerima julat panjang berversi sebelum penulis berubah. Penulis baharu boleh mengeluarkan kod yang lebih panjang manakala pemetaan lama terus diselesaikan tanpa perubahan. Pemisahan tidak boleh bergantung pada kedudukan aksara tetap yang dialih keluar oleh format baharu. Pantau ralat penyelesai dan penghuraian kunci cache, kemudian persarakan versi penulis lama; jangan sekali-kali menulis semula kod awam sedia ada semata-mata untuk menyeragamkan panjang.