Wawancara System Design: Merancang Layanan Distributed Lock

Masalah dan Cakupan (Problem and Scope)

Rancang layanan distributed lock yang diterapkan di tiga availability zone dalam satu region. Layanan ini mengelola 100.000 resource yang dapat dikunci, biasanya mempertahankan 20.000 lock aktif, dan menangani 2.000 akuisisi per detik pada puncaknya. Lease default adalah 30 detik, klien memperbarui setiap 10 detik, dan target p99 untuk akuisisi tanpa kontensi adalah 200 milidetik. Penyimpanan atau layanan yang dilindungi dapat membandingkan fencing token secara atomik dan menolak permintaan dari pemegang lama.

Skala, durasi lease, dan latensi adalah input wawancara, bukan klaim performa untuk etcd, ZooKeeper, atau produk lainnya. Cakupan mencakup exclusive lock, antrean tunggu, pembaruan, pelepasan, failover, dan observabilitas. Row lock database berbutir halus (fine-grained), transaction coordinator lengkap, mengimplementasikan konsensus dari awal, dan penguncian cross-region active-active berada di luar desain utama ini.

Ini adalah pertanyaan representatif untuk level senior backend, infrastruktur, dan system design. Panduan wawancara SDE II Amazon saat ini secara eksplisit mencakup system design dan mengevaluasi kepraktisan, akurasi, efisiensi, keandalan, optimasi, dan skalabilitas. Mode kegagalan utama menyentuh semuanya: layanan harus memulihkan lock setelah klien gagal tanpa membiarkan klien lama yang aktif kembali merusak data milik pemegang baru.

Hal yang Dievaluasi oleh Pewawancara (What the Interviewer Is Evaluating)

Pertama, dapatkah kandidat memisahkan keselamatan mutual-exclusion dari pembersihan kegagalan? Lease menjawab kapan pemegang lain boleh mengambil alih setelah pemegang saat ini menghilang. Lease tidak menghentikan klien yang sempat jeda lama untuk kembali aktif dan menulis. Desain yang ketat juga memerlukan fencing token dan validasi pada resource yang dilindungi.

Kedua, apakah batas konsistensi didefinisikan secara eksplisit? Akuisisi, pembaruan, dan pelepasan harus melewati satu state machine yang konsisten kuat (strongly consistent). Partisi minoritas tidak boleh terus menerbitkan lock. Jika tiga availability zone mengambil keputusan secara independen, partisi jaringan dapat menciptakan dua pemegang untuk resource yang sama.

Ketiga, apakah perencanaan kapasitas memperhitungkan lalu lintas pembaruan (renewal)? Dengan 20.000 lock aktif yang diperbarui setiap 10 detik, pembaruan saja menghasilkan sekitar 2.000 operasi per detik. Jika beban puncak juga memiliki 2.000 akuisisi per detik dan jumlah pelepasan yang serupa, state machine memerlukan sekitar 6.000 commit per detik, bukan hanya laju akuisisi.

Keempat, apakah semantik kegagalan mencakup tingkat permintaan? Jawaban harus mencakup akuisisi yang ter-commit tetapi kehilangan responsnya, klien yang terjeda melebihi masa lease, klien lama yang melepaskan lock milik pemegang baru, hilangnya kuorum, dan token yang monotonik di seluruh pergantian leader.

Terakhir, apakah kandidat tahu kapan tidak boleh menggunakan layanan ini? Google Chubby ditujukan untuk koordinasi tingkat kasar (coarse-grained). Jika database unique constraint, conditional update, single-consumer queue, atau business idempotency key sudah menyelesaikan masalah tersebut, remote lock hanya akan menambahkan titik kegagalan sinkron lainnya.

Pertanyaan Klarifikasi Sebelum Menjawab (Clarifying Questions Before Answering)

• Apakah kita membutuhkan exclusive lock atau reader-writer lock? Desain ini dimulai dengan exclusive lock. Reader-writer lock menambahkan

semantik state, upgrade, dan starvation yang tidak boleh dijanjikan sembarangan.

• Dapatkah resource yang dilindungi memvalidasi fencing token? Prompt ini mengasumsikan perbandingan atomik dan penyimpanan

token terbaru. Tanpa ini, lease hanya mengurangi jendela konflik dan tidak dapat secara ketat mengecualikan klien zombi.

• Seberapa adil antrean harus diatur? Default-nya adalah FIFO perkiraan. Keadilan mutlak mengurangi fleksibilitas selama pemulihan

dan di bawah beban kerja yang bervariasi.

• Berapa lama klien boleh menunggu? waitTimeout dibatasi dan dapat dibatalkan sehingga state antrean tidak membengkak tanpa batas.
• Bisakah durasi lease bervariasi berdasarkan beban kerja? Default-nya adalah 30 detik dengan pembaruan setiap 10 detik. Job yang panjang dapat

meminta durasi dalam batas kebijakan tertentu, tetapi lease tidak dapat diperpanjang tanpa batas.

• Bolehkah akuisisi dicoba ulang secara otomatis? Hanya percobaan ulang yang membawa requestId stabil yang sama yang aman. Jika tidak,

respons yang hilang akan meninggalkan hasil yang tidak diketahui.

• Apa yang terjadi tanpa kuorum? Keselamatan diutamakan: tolak akuisisi dan pembaruan baru. Setiap partisi tidak boleh menerbitkan lock.
• Apakah operasi yang dilindungi tetap harus idempoten? Ya. Fencing menolak epoch yang lebih lama; percobaan ulang bisnis dan

pengiriman duplikat tetap memerlukan business idempotency key atau transaksi.

• Apakah penguncian cross-region berlatensi rendah diperlukan? Desain utama adalah satu region di seluruh availability zone. Lock

cross-region yang ketat membayar latensi lebih tinggi atau kehilangan ketersediaan selama partisi dan termasuk dalam pertanyaan lanjutan.

Kerangka Jawaban 30 Detik (30-Second Answer Framework)

“Saya akan menyimpan state lock dalam state machine yang konsisten kuat yang direplikasi di tiga availability zone. Setiap akuisisi, pembaruan, dan pelepasan di-commit oleh kuorum. Akuisisi yang berhasil mengembalikan leaseId, masa berlaku 30 detik, dan fencingToken yang meningkat secara monotonik. Klien memperbarui setiap 10 detik dan berhenti bekerja ketika pembaruan tidak pasti. Setiap operasi yang dilindungi membawa token; resource menyimpan epoch tertinggi yang telah diterimanya dan menolak token yang lebih lama. Lease mengizinkan pemegang baru, sementara fencing menolak pemegang lama yang aktif kembali. requestId yang terdeduplikasi menangani akuisisi yang ter-commit namun kehilangan responsnya. Waiter yang terurut hanya memantau pendahulunya untuk menghindari thundering herd. Dua puluh ribu lock menghasilkan sekitar 2.000 pembaruan per detik; bersama akuisisi dan pelepasan, saya akan menguji sekitar 6.000 commit state per detik di bawah persistensi dan failover.”

Pembahasan Mendalam Langkah demi Langkah (Step-by-Step Deep Dive)

Mulailah dengan invarian alih-alih diagram komponen:

1. Untuk satu resource, state machine yang konsisten mencatat paling banyak satu leaseId yang valid pada satu waktu.
2. Setiap lock yang baru diperoleh menerima fencing token yang lebih besar.
3. Resource yang dilindungi menolak token yang lebih rendah dari token tertinggi yang telah diterimanya.
4. Hanya permintaan yang cocok dengan leaseId saat ini yang dapat memperbarui atau melepaskan.
5. Layanan tidak membuat lock atau mengklaim keberhasilan pembaruan tanpa mencapai kuorum.

Invarian ini memisahkan “siapa yang dianggap sebagai pemegang oleh layanan lock” dari “pekerjaan siapa yang masih akan diterima oleh resource.” State machine menentukan yang pertama; fencing pada batas efek samping menentukan yang kedua.

Langkah 1: Tentukan API dan state.

Acquire(resource, requestId, leaseTtl, waitTimeout)
  -> { leaseId, fencingToken, expiresAt }

Renew(resource, leaseId)
  -> { expiresAt }

Release(resource, leaseId)
  -> { released }

resource adalah pengenal bisnis yang dinormalisasi, bukan input pengguna mentah yang tak terbatas. leaseId adalah pengenal yang tidak dapat ditebak untuk epoch kepemilikan ini. fencingToken menggunakan revisi monotonik global dari log konsensus yang ter-commit, sementara setiap resource yang dilindungi menyimpan token tertinggi yang telah diterimanya. Hasil deduplikasi untuk requestId bertahan setidaknya selama jendela retry pemanggil. Pelepasan bersifat idempoten, tetapi pelepasan dengan leaseId lama tidak boleh menghapus lock milik pemegang baru.

Record lock berisi resource, leaseId, identitas pemegang, fencing token, masa kedaluwarsa, dan referensi waiter opsional. Record lock yang menganggur dapat dihapus, tetapi token tidak boleh mundur. Revisi monotonik global mencegah penyetelan ulang epoch suatu resource ke 1 setelah record-nya yang menganggur dihapus.

Langkah 2: Pilih batas replikasi yang konsisten kuat.

Gunakan consensus store atau sistem koordinasi yang terbukti untuk state machine; jangan mengimplementasikan ulang Raft atau Paxos di dalam layanan aplikasi. Tempatkan satu replika di masing-masing dari tiga availability zone. Leader mengembalikan keberhasilan hanya setelah setidaknya dua replika meng-commit perintah. Pembacaan state lock harus bersifat linearizable atau ditangani oleh leader; replika yang tertinggal tidak boleh menyatakan suatu resource bebas.

Jalur akuisisi normal memvalidasi parameter dan kunci deduplikasi, mengonfirmasi bahwa tidak ada lock atau bahwa state machine telah kedaluwarsa lease-nya, menetapkan leaseId dan revisi baru, meng-commit-nya ke kuorum, dan mengembalikan hasil. Jika leader gagal setelah commit tetapi sebelum responsnya tiba, retry dengan requestId yang sama akan mendapatkan hasil asli dari leader baru alih-alih membuat lease kedua.

Ketika hanya satu dari tiga replika yang tetap dapat dijangkau, layanan menolak akuisisi dan pembaruan. Ini mengurangi ketersediaan tetapi mempertahankan mutual-exclusion. Membiarkan minoritas memperbarui tampak membantu, tetapi setelah koneksi kembali normal, tidak ada cara aman untuk memperlakukan kedua pemegang yang terpartisi sebagai valid.

Langkah 3: Gunakan lease untuk memulihkan pemegang yang gagal.

Lease default adalah 30 detik dan klien memperbarui setiap 10 detik, menyisakan dua interval pembaruan untuk variasi latensi (jitter) dan kegagalan sementara. Waktu lease otoritatif dikelola oleh state machine koordinasi di sisi server. Jam lokal klien dapat menentukan kapan harus mencoba pembaruan, tetapi tidak dapat membuktikan kepemilikan. Setelah kegagalan pembaruan berulang kali atau respons yang tidak pasti, klien memasuki status diam (quiescent), tidak memulai pekerjaan baru, dan menghentikan pekerjaan in-flight yang dapat diinterupsi sesegera mungkin.

Pergantian leader harus menangani sisa waktu lease secara konservatif; jam yang lebih cepat pada leader baru tidak boleh menyerahkan lock kepada pihak lain terlalu dini. Sistem produksi harus menggunakan kembali implementasi lease yang teruji dan memasukkan clock skew maksimum, waktu pemilihan leader, dan network retry ke dalam anggaran lease. Memotong lease menjadi ratusan milidetik meningkatkan kecepatan pembersihan tetapi mengubah jitter biasa menjadi hilangnya lock yang sering.

Langkah 4: Gunakan fencing token untuk menghentikan klien zombi.

Misalkan klien A memperoleh token 41 dan kemudian terhenti karena garbage collection yang lama. Lease 30 detiknya kedaluwarsa, klien B memperoleh token 42, dan B mulai bekerja. A aktif kembali tanpa mengetahui bahwa ia telah kehilangan lock dan mengirimkan write yang tertunda. Jika penyimpanan hanya tahu bahwa A pernah memperoleh lock, write usang tersebut dapat menimpa hasil baru milik B.

Oleh karena itu, setiap permintaan yang dilindungi membawa tokennya. Penyimpanan secara atomik mengingat epoch tertinggi yang terlihat untuk setiap resource. Setelah menerima token 42, penyimpanan menolak setiap permintaan dengan token 41. Beberapa operasi dengan token yang sama mungkin masih sah; pengurutan, idempotensi, dan konflik versinya menjadi tanggung jawab protokol bisnis. Pembandingan menolak token yang lebih rendah dari epoch terbaru alih-alih menolak token yang sama secara membabi buta.

Dokumentasi etcd menegaskan batasan yang sama: lease saja tidak menjamin mutual-exclusion atas resource eksternal; resource tersebut harus memvalidasi versi. Jika target tidak dapat menyimpan atau membandingkan token, desain tidak dapat menjanjikan keselamatan yang ketat. Alternatifnya mencakup database conditional update, unique constraint, native transactional lock, single-writer queue, atau write proxy yang dapat menegakkan token tersebut.

Langkah 5: Tangani antrean tunggu, keadilan, dan thundering herd.

Untuk resource dengan kontensi rendah, pemanggil yang gagal dapat mencoba lagi dengan exponential backoff dan jitter. Untuk resource panas (hot resource) yang memerlukan antrean tunggu, tetapkan sequence number yang meningkat dan biarkan setiap waiter hanya memantau pendahulu langsungnya. Ketika pendahulu melepaskan atau kedaluwarsa, hanya waiter berikutnya yang terbangun alih-alih setiap klien berebut sekaligus. Pola lock milik ZooKeeper menggunakan ephemeral sequential node dan pemantauan pendahulu karena alasan ini.

Antrean ini menyediakan FIFO perkiraan, bukan keadilan mutlak. Pembatalan, batas waktu (timeout), dan kedaluwarsa sesi akan menghapus wait node. Jika respons terhadap pembuatan node hilang, requestId akan menemukan node asli alih-alih menambahkan yang lain. Batas waiter per-resource dan per-tenant mencegah satu hot lock menghabiskan memori.

Langkah 6: Estimasi kapasitas dan pemartisian.

Dua puluh ribu lock aktif yang diperbarui setiap 10 detik menghasilkan sekitar 2.000 pembaruan per detik. Pada puncak 2.000 akuisisi per detik, dan dengan asumsi pelepasan kira-kira sama dengan akuisisi, state machine konsensus menangani sekitar 2,000 + 2,000 + 2,000 = 6,000 write commit per detik. Record antrean (enqueue), pembatalan, kedaluwarsa, dan deduplikasi menambahkan amplifikasi penulisan (write amplification). Uji kapasitas harus menggabungkan lalu lintas puncak, hilangnya satu replika, dan pemadatan log (log compaction).

Jika 100.000 resource masing-masing menyimpan sekitar 500 byte state logis, total logisnya adalah sekitar 50 MB. Replika, log, indeks, waiter, dan overhead storage engine meningkatkan ukuran fisik secara substansial. Persistensi sinkron, resource panas, dan volume pembaruan lebih mungkin menjadi bottleneck di sini daripada ukuran record statis.

Mulailah dengan satu grup konsensus untuk skala yang disebutkan. Lakukan partisi berdasarkan hash dari resource hanya jika pengukuran menunjukkan bahwa satu grup gagal mencapai target. Sharding meningkatkan aggregate throughput tetapi tidak dapat membagi satu resource yang sangat panas, dan ini memperumit penguncian atomik di beberapa resource. Desain ini tidak menjanjikan transactional lock multi-resource. Jika pemanggil harus mengunci beberapa resource, mereka menggunakan urutan tetap dan batas waktu keseluruhan, atau domain dimodelkan ulang sebagai satu resource tingkat lebih tinggi.

Langkah 7: Tutup loop kegagalan dan operasional.

• Kegagalan leader: leader baru memulihkan state yang ter-commit; requestId menyelesaikan permintaan dengan respons yang tidak diketahui secara aman.
• Partisi jaringan: hanya kuorum yang melayani; minoritas menolak, dan fencing akhirnya menolak write pemegang lama.
• Jeda klien: lock baru dapat diterbitkan setelah kedaluwarsa, sementara klien yang aktif kembali gagal dalam validasi token di sisi resource.
• Hot lock: ukur panjang antrean, latensi akuisisi, dan waktu penahanan; batasi antrean dan pertimbangkan antrean kerja atau job yang dipartisi.
• Badai pembaruan (renewal storm): tambahkan jitter pada jadwal klien dan prioritaskan lease yang paling mendekati kedaluwarsa alih-alih memperbarui setiap lock secara bersamaan.
• Resource tanpa validasi token: turunkan jaminan secara eksplisit menjadi best-effort exclusion atau larang penulisan data keuangan dan inventaris yang ketat.

Metrik inti mencakup p50/p95/p99 akuisisi, pembaruan, dan pelepasan; hasil sukses, timeout, konflik, dan tidak diketahui; lock aktif, waiter, kedaluwarsa, kegagalan pembaruan, durasi pemilihan leader, latensi commit konsensus, penolakan fencing, dan hot resource. Audit log mencatat resource, leaseId, token, pemanggil, dan hasil tanpa payload sensitif.

Validasi melampaui unit test. Pengujian model state machine memeriksa kepemilikan tunggal dan token yang monotonik. Fault injection mencakup respons yang hilang setelah commit, klien yang terjeda melebihi 30 detik, write lama yang tertunda, isolasi satu replika, hilangnya mayoritas, pergantian leader, dan pembatalan waiter. Asersi end-to-end yang kritis adalah: setelah resource menerima token 42 milik B, token 41 milik A tidak akan pernah dapat mengubah resource tersebut lagi.

Contoh Jawaban Berkualitas Tinggi (High-Quality Sample Answer)

“Saya akan mulai dengan target keselamatan: satu resource memiliki paling banyak satu lease yang valid dalam state lock yang konsisten kuat, dan resource yang dilindungi tidak pernah menerima write dari pemegang lama. Layanan ini berjalan di tiga availability zone pada consensus store yang terbukti. Akuisisi, pembaruan, dan pelepasan memerlukan kuorum. Jika hanya ada minoritas, layanan menolak permintaan alih-alih mengorbankan mutual-exclusion demi ketersediaan.

API mengembalikan leaseId, masa kedaluwarsa, dan fencingToken yang meningkat secara monotonik. Lease default adalah 30 detik dan klien memperbarui setiap 10 detik. Jam lokalnya hanya menjadwalkan pembaruan; jika pembaruan tidak pasti, klien berhenti bekerja. Lease mengizinkan pengambilalihan setelah kegagalan, tetapi resource adalah batas keselamatan yang sebenarnya: setiap permintaan yang dilindungi membawa token, dan resource menyimpan epoch tertinggi yang telah diterimanya serta menolak yang lebih lama. Jika klien pemegang token 41 aktif kembali setelah token 42 mengambil alih, write usangnya tidak dapat diterapkan.

Setiap akuisisi membawa requestId. Jika layanan telah meng-commit tetapi kehilangan responsnya, pemanggil mencoba lagi dengan ID yang sama dan menerima lease asli alih-alih membuat yang lain. Pembaruan dan pelepasan harus cocok dengan leaseId saat ini, sehingga klien lama tidak dapat melepaskan lock milik pemegang baru. Untuk lock yang diperebutkan, waiter yang terurut hanya memantau pendahulunya, memberikan FIFO perkiraan tanpa thundering herd.

Untuk kapasitas, 20.000 lock yang diperbarui setiap 10 detik sudah menghasilkan sekitar 2.000 write per detik. Menambahkan 2.000 akuisisi dan tingkat pelepasan yang serupa menghasilkan sekitar 6.000 commit konsensus per detik. Saya akan memverifikasi target p99 200 milidetik saat satu replika mati dan pemadatan log sedang berjalan alih-alih mengutip benchmark vendor. Saya akan mulai dengan satu grup konsensus dan melakukan sharding berdasarkan resource hanya jika uji beban membuktikan hal itu diperlukan.

Terakhir, pengujian model dan fault injection mencakup hilangnya respons setelah commit, jeda klien, paket tertunda, partisi, pemilihan leader, dan pembatalan waiter. Saya akan memantau latensi akuisisi dan pembaruan, konflik, kedaluwarsa, panjang antrean, pemilihan leader, dan penolakan fencing. Jika sistem yang dilindungi tidak dapat membandingkan token secara atomik, saya akan menyatakan bahwa mutual-exclusion yang ketat tidak tersedia dan lebih memilih database conditional update, unique constraint, atau single-writer queue.”

Kesalahan Umum (Common Mistakes)

• Hanya menyimpan key dengan TTL → klien lama yang terjeda dapat aktif kembali dan menulis → terbitkan token monotonik untuk setiap akuisisi dan validasi pada resource.
• Membiarkan setiap availability zone menerbitkan lock → partisi menciptakan banyak pemegang → arahkan setiap perubahan state melalui satu state machine yang didukung kuorum.
• Memperlakukan jam klien sebagai kebenaran lease → clock skew dan jeda menyebabkan kepemilikan palsu → kelola lease di sisi server dan minta klien yang ragu untuk berhenti.
• Mencoba lagi akuisisi dengan request ID baru → permintaan asli mungkin sudah ter-commit → gunakan requestId yang stabil untuk mengambil hasil pertama.
• Mengizinkan pelepasan hanya dengan nama resource → permintaan lama dapat menghapus lock milik pemegang baru → wajibkan leaseId saat ini untuk pembaruan dan pelepasan.
• Hanya mengalokasikan kapasitas untuk 2.000 akuisisi per detik → 2.000 pembaruan dan pelepasan serupa terlewatkan → uji baseline sekitar 6.000 commit state per detik.
• Membuat setiap waiter memantau root lock → setiap pelepasan membangunkan seluruh antrean → buat setiap waiter hanya memantau pendahulu langsungnya.
• Langsung melakukan sharding ke banyak grup konsensus → operasional dan semantik lintas-resource menjadi rumit di awal → ukur satu grup terlebih dahulu, lalu lakukan sharding berdasarkan bukti.
• Menggunakan distributed lock untuk setiap baris tabel → koordinasi menjadi jalur transaksi frekuensi tinggi dan bottleneck → pilih constraint atomik database untuk konkurensi tingkat halus.
• Mengklaim keselamatan ketat saat target tidak dapat memvalidasi token → lease tidak dapat menghentikan write usang yang tertunda → turunkan tingkat jaminan atau ubah batas penulisan.

Pertanyaan Lanjutan dan Tanggapan (Follow-up Questions and Responses)

Pertanyaan Lanjutan 1: Mengapa fencing token diperlukan jika lock sudah memiliki lease?

Lease hanya mengizinkan layanan lock untuk memberikan lock kepada B setelah 30 detik. Lease tidak dapat membatalkan operasi yang sudah dikirimkan A ke sistem eksternal tetapi masih berada dalam antrean jaringan atau proses. A juga dapat aktif kembali setelah jeda yang lama tanpa mengetahui bahwa masa lease-nya telah berakhir. Begitu resource menerima token 42, penolakan terhadap token 41 akan menghentikan pekerjaan dari epoch lama tepat di titik di mana efek samping terjadi. Aturan yang dapat digunakan kembali adalah: lease menentukan kapan pemegang baru boleh dipilih; fencing menentukan apakah pekerjaan milik pemegang lama masih diterima.

Pertanyaan Lanjutan 2: Bagaimana jika database yang dilindungi tidak dapat menyimpan fencing token?

Pertama, cari kondisi versi atomik yang setara seperti UPDATE ... WHERE version = expected, unique constraint, transactional lock, atau database advisory lock. Penulisan juga dapat melewati proxy atau single-consumer queue yang memvalidasi token tersebut. Jika tidak ada yang memungkinkan, jaminannya hanyalah best-effort exclusion; jeda proses dan pesan yang tertunda masih dapat merusak kebenaran data. Alur kerja keuangan dan inventaris tidak boleh menerima klaim yang ambigu.

Pertanyaan Lanjutan 3: Bagaimana Anda merancang lock global di seluruh region?

Desain langsung memberikan home region untuk setiap resource dan membuat setiap region menggunakan satu kuorum lintas-region. Hal itu menambah latensi penulisan jarak jauh, dan region minoritas tidak dapat melakukan akuisisi selama partisi jaringan. Lock regional yang independen tidak dapat digabungkan secara asinkron karena konflik mutual-exclusion tidak dapat dibatalkan di kemudian hari. Jika ketersediaan regional lebih penting, partisikan kepemilikan resource sehingga satu resource hanya dapat ditulis di satu region alih-alih menciptakan sistem penguncian global active-active.

Pertanyaan Lanjutan 4: Bagaimana Anda memilih lease 30 detik dan interval pembaruan 10 detik?

Keduanya adalah input dari prompt. Nilai sebenarnya bergantung pada jeda proses normal terlama, p99 jaringan, waktu pemilihan leader, anggaran kesalahan jam, dan waktu pemulihan kegagalan yang dapat diterima. Lease yang terlalu pendek memperlakukan jitter normal sebagai hilangnya lock; lease yang terlalu panjang menunda pemulihan dari pemegang yang gagal. Pembaruan 10 detik memberikan dua peluang tambahan dalam lease 30 detik. Tambahkan jitter acak agar 20.000 klien tidak menciptakan lonjakan pembaruan yang tersinkronisasi.

Pertanyaan Lanjutan 5: Bagaimana Anda mendukung akuisisi beberapa lock sekaligus?

Batasan paling sederhana adalah bahwa layanan ini tidak menawarkan penguncian lintas-resource yang atomik. Pemanggil memperoleh nama resource yang dinormalisasi dalam urutan tetap dengan batas waktu keseluruhan yang singkat, dan melepaskannya dalam urutan terbalik jika terjadi kegagalan. Ini mengurangi deadlock tetapi bukan atomisitas transaksional. Jika domain benar-benar membutuhkan akuisisi all-or-nothing, modelkan kumpulan tersebut sebagai satu resource tingkat lebih tinggi atau simpan semua key dalam satu transaksi konsensus dan terima konsekuensi throughput serta kompleksitasnya.

Pertanyaan Lanjutan 6: Bagaimana Anda membuktikan implementasi ini tidak pernah menciptakan dua pemegang yang valid?

Gunakan model state machine untuk menghasilkan urutan akuisisi, pembaruan, pelepasan, kedaluwarsa, dan retry, guna memastikan bahwa setiap posisi log memiliki paling banyak satu leaseId yang valid dan bahwa token selalu meningkat. Kemudian lakukan fault injection: hilangkan respons setelah commit, hentikan A melebihi durasi lease, biarkan B memperoleh lock dan menulis, lalu aktifkan kembali A dengan write lamanya; resource harus menolak token lama tersebut. Selain itu, isolasi minoritas dan mayoritas, ganti leader berulang kali, batalkan waiter, dan periksa setiap riwayat konkurensi terhadap invarian yang telah ditetapkan.