Topik wawancara representatif

Wawancara Desain Sistem: Bagaimana Anda mendesain registri artefak dan paket?

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Desain registri tempat tim memublikasikan dan mengunduh paket, image kontainer, atau artefak build. Jelaskan API, penyimpanan, resolusi versi, konkurensi, izin, caching, pencabutan, dan verifikasi integritas.

Petunjuk dan konteks

Desain registri tempat tim memublikasikan dan mengunduh paket, image kontainer, atau artefak build. Cakup metadata, blob biner, tag versi, izin, ketersediaan, caching, pencabutan, dan audit.

Pilih satu bentuk artefak terlebih dahulu dan jelaskan abstraksi mana yang digeneralisasi. Batasan utamanya adalah satu salinan per digest konten, tidak ada rilis yang terlihat sebagian, dan verifikasi klien bahwa byte tidak diganti.

Apa yang sedang diuji oleh pewawancara

Metadata versus konten

Jawaban yang kuat memisahkan metadata paket, versi, tag, dependensi, dan tanda tangan dari blob konten yang tidak dapat diubah (immutable), sehingga pembacaan metadata tidak memindai file besar.

Semantik versi dan konsistensi

Jelaskan pembuatan versi semantik (semantic versioning), tag yang berpindah (moving tags), publikasi bersamaan (concurrent publishes), dan penghapusan. Resolver yang buruk membuat build tidak dapat direproduksi.

Distribusi dan biaya

Diskusikan unggahan terfragmentasi (chunked uploads), kemampuan melanjutkan (resumability), pengalamatan konten (content addressing), CDN, replikasi lintas-wilayah, dan pengumpulan sampah (garbage collection) daripada hanya menggambar penyimpanan objek (object store).

Keamanan dan tata kelola

Izin, isolasi tenant, penandatanganan, SBOM, pemindaian malware, audit, dan pencabutan harus membentuk satu putaran operasional.

Pertanyaan klarifikasi yang perlu diajukan

  • Apakah ini paket seperti npm, image OCI, atau file build arbitrer?
  • Berapa tingkat publikasi/unduh harian dan total penyimpanan?
  • Bisakah tag seperti latest berpindah?
  • Bisakah versi yang dipublikasikan ditimpa, atau hanya diikuti oleh versi baru?
  • Apakah tenant privat, proksi upstream, dan pemulihan multi-wilayah diperlukan?
  • Apakah pencabutan memblokir unduhan baru, menghapus byte, atau menandai risiko sambil tetap menyimpan bukti?

Kerangka jawaban 30 detik

“Saya akan memulai dengan registri multi-tenant beralamat konten (content-addressed). Penerbit mengunggah dan memverifikasi blob, lalu mengomit manifes yang tidak dapat diubah; tag hanya menunjuk ke versi yang ada dan berpindah di bawah kondisi konkurensi. Klien membaca metadata, mengambil blob berdasarkan digest dari penyimpanan objek atau CDN, dan memverifikasi digest serta tanda tangan. Izin mencakup namespace dan tindakan. Pencabutan menandai risiko tanpa langsung menghapus bukti audit. Artefak populer menggunakan CDN; replikasi, pemindaian, dan pengumpulan sampah berjalan secara asinkron.”

Penyelaman mendalam langkah demi langkah

Langkah 1: Tentukan model sumber daya

Sumber daya terdiri dari namespace, paket, versi, tag, manifes, blob, tanda tangan, dan asal-usul (provenance). Manifes mereferensikan digest, jenis media, dan ukuran; blob tidak dapat diubah pada digest tersebut.

Langkah 2: Desain penerbitan

Klien meminta sesi unggahan dan mengirimkan potongan (chunks) ke penyimpanan sementara. Layanan memverifikasi setiap potongan dan digest akhir, lalu mengomit manifes secara atomik. Sesi yang kedaluwarsa dibersihkan; digest yang sudah ada digunakan kembali.

Langkah 3: Tangani versi dan tag

Versi yang tidak dapat diubah tidak dapat ditimpa. Tag dapat berpindah, tetapi operator, target lama dan baru, serta versi kondisional dicatat. Resolusi dependensi lebih memilih versi dan digest yang dipasangi pin daripada latest.

Langkah 4: Desain pengunduhan

Metadata mengembalikan manifes, dependensi, dan tanda tangan. Pengiriman blob mendukung range requests, ETag, dan CDN. Klien memverifikasi digest; digest adalah kunci cache, sedangkan resolusi tag memiliki TTL yang pendek.

Langkah 5: Skalakan dan pulihkan

Penyimpanan objek menampung blob besar, sementara metadata dipartisi berdasarkan namespace dan paket. Replikasi manifes sebelum atau bersamaan dengan blob dan ekspos wilayah baru hanya jika kebijakan pembacaannya terpenuhi.

Langkah 6: Amankan dan operasikan

Gunakan tindakan membaca, menulis, menerbitkan, memindahkan tag, dan menghapus dengan hak istimewa terendah (least-privilege). Pindai malware, buat SBOM, verifikasi tanda tangan dan asal-usul, serta tulis setiap tindakan ke log audit. Versi yang dicabut akan diblokir untuk unduhan baru sementara bukti mengikuti kebijakan retensi.

Model jawaban berkualitas tinggi

“Saya akan membagi registri menjadi metadata, penyimpanan blob, dan tugas tata kelola asinkron. Klien membuat sesi unggahan terfragmentasi; setelah verifikasi digest, transaksi mengomit manifes yang mereferensikan blob yang tidak dapat diubah. Versi tidak dapat ditimpa; perpindahan tag menggunakan versi kondisional dan menyimpan riwayat. Pengunduhan menyelesaikan versi yang dipasangi pin, mengambil berdasarkan digest dari CDN atau penyimpanan objek, dan memverifikasi tanda tangan.

Caching beralamat konten dan range requests mengurangi biaya blob panas. Tugas latar belakang mereplikasi lintas wilayah, memindai malware, dan melampirkan SBOM serta asal-usul. Namespace privat menerapkan izin dan kuota tenant. Pencabutan menandai suatu versi diblokir, menghentikan unduhan baru, dan memperingatkan sistem build tanpa menghapus bukti audit. Saya akan melacak keberhasilan publikasi, latensi p95 pengunduhan, rasio hit cache, kelambatan replikasi, dan akses tanpa izin.”

Kesalahan umum

  • Membiarkan klien memutasi penyimpanan objek → izin dan integritas dilewati → gunakan sesi unggahan berumur pendek dan commit manifes di sisi server.
  • Mengizinkan penimpaan versi yang dipublikasikan → build tidak dapat direproduksi → buat versi tidak dapat diubah dan publikasikan versi baru.
  • Menggunakan latest sebagai kunci cache permanen → byte bergeser secara diam-diam → cache berdasarkan digest dan selesaikan tag dengan TTL pendek.
  • Hanya menyimpan byte → dependensi dan tanda tangan hilang → pertahankan manifes terstruktur dan asal-usul.
  • Membuat setiap wilayah dapat dibaca secara instan → artefak parsial menjadi terlihat → batasi pembacaan berdasarkan status manifes, blob, dan kebijakan.
  • Menghapus artefak yang dicabut → bukti audit dan insiden hilang → tandai diblokir dan bersihkan secara asinkron berdasarkan aturan retensi.
  • Hanya memeriksa login → akses lintas-tenant dapat bocor → otorisasi namespace, tindakan, dan artefak di setiap batas.
  • Memblokir publikasi saat pemindaian berlangsung → latensi unggahan melonjak → karantina terlebih dahulu, pindai secara asinkron, lalu ubah status ketersediaan.

Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Dua penerbit memindahkan tag yang sama secara bersamaan. Apa yang terjadi?

Gunakan versi kondisional atau compare-and-swap. Kembalikan versi saat ini jika terjadi konflik sehingga klien mencoba kembali dengan riwayat yang terlihat; jangan pernah secara diam-diam menggunakan last-write-wins.

Pertanyaan lanjutan 2: Bagaimana Anda menjamin pengunduhan yang lengkap?

Manifes mendeklarasikan digest, ukuran, dan jenis media. Klien memverifikasi digest dan mencoba kembali ke replika lain jika gagal; layanan memantau kegagalan verifikasi.

Pertanyaan lanjutan 3: Bisakah publikasi dilanjutkan saat replikasi mengalami kelambatan (lag)?

Wilayah utama dapat menerima rilis dan menandainya sedang mereplikasi. Wilayah target hanya mengiklankannya setelah manifes yang diperlukan, blob dependensi, dan status kebijakan konsisten.

Pertanyaan lanjutan 4: Bagaimana Anda mengumpulkan sampah (garbage-collect) blob duplikat?

Bangun himpunan referensi dari manifes aktif, tanda tangan, dan kebijakan retensi. Tandai blob yang tidak direferensikan, tunggu masa tenggang (grace period), periksa ulang konkurensi, lalu hapus.

Pertanyaan lanjutan 5: Bagaimana asal-usul (provenance) memengaruhi keputusan pengunduhan?

Kaitkan tanda tangan, SBOM, dan asal-usul dengan manifes. Mesin kebijakan memutuskan untuk mengizinkan, mengkarantina, atau memperingatkan berdasarkan tenant, lingkungan, dan risiko artefak.

Sumber 1: OCI Distribution Specification

Spesifikasi OCI memusatkan distribusi pada manifes, deskriptor, dan blob serta mendefinisikan semantik push, pull, digest, dan error untuk registri beralamat konten.

Sumber 2: Metadata npm Registry

Metadata npm Registry menunjukkan versi, dist-tags, dan informasi paket sebagai perhatian terpisah, mendukung aturan konsistensi dan caching yang berbeda untuk tag dan versi yang tidak dapat diubah.

Sumber 3: Integritas rantai pasokan SLSA

Pengenalan SLSA dari Google menekankan asal-usul artefak, keterlacakan, dan ketahanan terhadap manipulasi. Sinyal-sinyal tersebut dapat melengkapi penandatanganan registri, SBOM, pemindaian, dan kebijakan pengunduhan.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat