Konteks dan cakupan
Anda mengelola SaaS global di mana kegagalan basis data, antrean, atau deployment pada satu klaster dapat memengaruhi setiap tenant. Rancang cell-based architecture: setiap cell adalah salinan lengkap dari sistem yang dapat beroperasi secara independen dan melayani serangkaian tenant tetap, dan sebuah entry layer merutekan permintaan ke cell target berdasarkan pemetaan yang stabil.
Cakupi partisi tenant, direktori perutean, batas komputasi dan data di dalam cell, pelaporan lintas-cell, rilis, migrasi, kapasitas, serta disaster recovery. AWS mendeskripsikan cell sebagai replika independen dan menyimpan pemetaan pengguna-ke-cell dalam penyimpanan dengan ketersediaan tinggi; panduan bulkhead-nya menjelaskan perutean berdasarkan partition key di balik satu endpoint.
Hal yang dievaluasi pewawancara
- Apakah Anda mendefinisikan cakupan kegagalan, konsistensi tenant, dan degradasi yang dapat diterima terlebih dahulu.
- Apakah sebuah cell merupakan domain kegagalan yang nyata, bukan sekadar duplikasi layanan stateless.
- Apakah Anda mengidentifikasi risiko perutean, control-plane, dependensi bersama, dan kueri lintas-cell.
- Apakah penambahan cell baru, penyeimbangan ulang (rebalancing), dan migrasi tenant memiliki langkah-langkah yang dapat dibatalkan (reversible).
- Apakah metrik kapasitas, error, dan dependensi tingkat cell membuktikan klaim blast-radius.
Referensi wawancara system design memperlakukan cell-based architecture sebagai pola isolasi untuk sistem berskala sangat besar. Jawaban yang kuat menjelaskan kapan manfaat keandalan sebanding dengan duplikasi infrastruktur dan operasi; cell bukanlah sinonim dari microservice.
Pertanyaan klarifikasi sebelum menjawab
- Apakah cakupan kegagalan yang ditargetkan adalah satu tenant, satu cell, satu Availability Zone, atau satu region?
- Bolehkah tenant berbagi data, pencarian global, atau agregasi lintas-tenant?
- Operasi mana yang memerlukan linearizability, dan laporan mana yang boleh tertunda atau konsisten pada akhirnya (eventually consistent)?
- Bisakah migrasi berlangsung dalam status read-only secara singkat? Apakah ada kendala residensi data?
- Berapa target ketersediaan, jumlah tenant, pertumbuhan, kapasitas cell, dan frekuensi rilis?
Kerangka jawaban 30 detik
Saya akan memetakan tenant key yang stabil ke sebuah cell tetap. Setiap cell memiliki komputasi, antrean, cache, dan penyimpanan data utama sendiri; control plane global hanya mengelola versi, kapasitas, dan pemetaan. Sebuah entry router membaca direktori berketersediaan tinggi dan hanya mengisolasi cell yang gagal. Laporan lintas-cell menggunakan agregasi asinkron sehingga kueri tidak membuat ulang basis data bersama. Pembuatan, migrasi, dan rilis cell menggunakan langkah-langkah kecil, teramati, dan dapat dibatalkan, dengan SLO tingkat cell yang membuktikan batas kegagalan.
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan batas cell dan asumsi kegagalan
Definisikan cell sebagai salinan lengkap yang dapat di-deploy dan dipulihkan secara independen: API, worker, cache, basis data, prefiks penyimpanan objek, dan pemantauan. Layanan identitas, penagihan (billing), atau konfigurasi bersama memerlukan anggaran kegagalan (failure budget) yang eksplisit. Jika control plane bersama memblokir setiap cell saat tidak tersedia, data plane belum sepenuhnya terisolasi.
Langkah 2: Pilih partition key dan direktori perutean
Gunakan tenant_id sebagai partition key yang stabil. Direktori menyimpan pemetaan tenant-ke-cell, versi, status migrasi, dan kapasitas. Router membaca cache lokal terlebih dahulu dan menyegarkannya dari direktori berketersediaan tinggi; nomor versi dan lease mencegah rute lama menulis ke dua cell selama migrasi. Klien melihat satu hostname sementara router mengelola batas percobaan ulang (retry).
Langkah 3: Bangun data plane di dalam cell
Setiap cell memiliki basis data utama dan antrean pesan sendiri; data tenant tidak ditulis secara sinkron di seluruh cell. Replika, cache, dan penyimpanan objek membawa identitas cell, dan cadangan (backup) mempertahankan metadata tersebut. Konfigurasi global menggunakan snapshot read-only atau rollout berversi alih-alih mengirimkan traffic aktif ke satu basis data global.
Langkah 4: Tangani kueri lintas-cell
Setiap cell memancarkan change stream untuk membangun tabel agregat yang digunakan oleh lapisan analitik global. Laporan menyertakan stempel waktu data dan penanda cell yang hilang daripada mengklaim kelengkapan secara real-time. Operasi lintas-tenant yang sangat konsisten (strongly consistent) harus dipersempit, dibuat asinkron, atau secara eksplisit menerima domain kegagalan bersama yang lebih besar; hindari two-phase commit pada jalur permintaan.
Langkah 5: Rancang jalur kegagalan dan degradasi
Pemeriksaan kesehatan (health check) mencakup dependensi di dalam cell, keterjangkauan rute, dan kebenaran bisnis. Ketika sebuah cell gagal, direktori menandainya sebagai draining dan menghentikan permintaan baru; cache baca atau pekerjaan asinkron dapat mengalami degradasi jika produk mengizinkan. Jangan memindahkan tenant ke cell arbitrer sampai batas replikasi, idempotensi, dan otorisasi terbukti, atau failover dapat menyebabkan penulisan ganda.
Langkah 6: Tambahkan cell dan seimbangkan ulang kapasitas
Buat cell kosong dari template infrastruktur, jalankan traffic sintetis dan pembacaan bayangan (shadow reads), lalu izinkan sekumpulan kecil tenant masuk. Sinyal kapasitas mencakup CPU, koneksi basis data, penundaan antrean, pertumbuhan penyimpanan, dan biaya per tenant. Penyeimbangan ulang membekukan versi pemetaan, menyalin dan memverifikasi data, melakukan handoff penulisan singkat, serta mengawasi cell lama dan baru; jika terjadi kegagalan, lakukan rollback pemetaan alih-alih menghapus data lama.
Langkah 7: Kelola rilis dan versi
Rilis control plane, template cell, dan versi bisnis secara terpisah. Lakukan canary release di satu cell, lalu perluas cell demi cell. Pertahankan jendela kompatibilitas sehingga versi baru tidak menulis bidang (field) yang tidak dapat dibaca oleh versi lama. Buat distribusi versi dan error terlihat berdasarkan cell; rata-rata global tidak boleh menyembunyikan satu versi yang bermasalah.
Langkah 8: Verifikasi blast radius dan biaya operasional
Injeksikan kegagalan basis data, antrean, direktori perutean, dan deployment ke dalam satu cell lalu pastikan hanya tenant yang diharapkan yang terdampak. Lacak ketersediaan cell, error budget, pangsa permintaan lintas-cell, waktu rollback migrasi, ketergantungan pada control-plane bersama, dan kapasitas cadangan. Jika jumlah cell terlalu sedikit untuk mengisolasi gangguan atau biaya operasi duplikat melebihi keuntungan keandalan, pilih desain partisi atau bulkhead yang lebih sederhana.
Contoh jawaban
Saya akan memetakan tenant_id ke sebuah cell tetap. Setiap cell secara independen menjalankan API, antrean, cache, dan penyimpanan utama; control plane hanya mengelola versi, kapasitas, dan pemetaan. Router dengan hostname tunggal membaca direktori berversi dengan ketersediaan tinggi, dan cell yang gagal akan di-drain alih-alih menerima penulisan yang belum diverifikasi di tempat lain. Pelaporan lintas-cell bersifat asinkron melalui change stream. Migrasi menggunakan penyalinan, verifikasi, handoff singkat, dan pemetaan yang dapat dibatalkan. Saya akan membuktikan klaim blast-radius dengan SLO cell, pangsa dependensi bersama, waktu rollback, dan uji simulasi kegagalan; jika biaya isolasi melebihi manfaatnya, saya akan menggunakan bulkhead yang lebih sederhana.
Kesalahan umum
- Hanya menduplikasi layanan stateless → basis data bersama tetap menjadi titik kegagalan tunggal (single point of failure) → tetapkan batas data dan antrean di setiap cell.
- Memindahkan tenant secara acak saat terjadi kegagalan → penulisan duplikat atau ketidakcocokan otorisasi → buktikan replikasi, idempotensi, dan versi rute terlebih dahulu.
- Mengagregasi lintas cell pada jalur permintaan → menciptakan domain kegagalan global baru → gunakan agregasi asinkron dengan penanda waktu data.
- Hanya menggunakan pemeriksaan kesehatan global → cell yang bermasalah tersembunyi oleh rata-rata → catat SLO tingkat cell dan distribusi versi.
- Mengubah rute secara langsung selama migrasi → penulisan lama dan baru tumpang tindih → gunakan versi pemetaan, verifikasi salinan, dan rollback.
- Memberikan cell tersendiri untuk setiap dependensi → biaya dan operasional tidak terkendali → kuantifikasi blast radius dan manfaat kapasitas terlebih dahulu.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika direktori perutean gagal?
Pertahankan cache lokal berversi dan snapshot read-only, batasi perubahan pemetaan, dan biarkan tenant yang ada melanjutkan aktivitas pada cell aslinya. Jangan melakukan rebalancing secara luas hingga direktori pulih.
Bagaimana jika laporan admin harus bersifat real-time di seluruh cell?
Klarifikasi penundaan yang diizinkan dan semantik data yang hilang. Konsistensi yang kuat mungkin memerlukan penyempitan operasi atau penerimaan domain kegagalan bersama yang lebih besar; laporan normal harus menggunakan agregat asinkron berstempel waktu.
Bagaimana cara memigrasikan tenant saat sebuah cell penuh?
Salin dan verifikasi data, publikasikan versi pemetaan baru, koordinasikan handoff penulisan singkat, dan naikkan traffic secara bertahap. Pertahankan cell lama hingga konsistensi terbukti; lakukan rollback pemetaan jika tidak konsisten.
Apakah aman menerapkan satu versi hanya ke beberapa cell?
Ya, dengan skema yang kompatibel, observabilitas versi, dan urutan peluncuran (rollout) yang eksplisit. Tingkat keberhasilan global tidak dapat menggantikan error budget per cell.
Bagaimana Anda membuktikan bahwa kegagalan tidak menyebar?
Lakukan simulasi kegagalan basis data, antrean, perutean, dan deployment di dalam satu cell. Catat tenant yang terdampak, permintaan lintas-cell, waktu pemulihan, dan panggilan dependensi bersama.
Kapan sebaiknya Anda tidak menggunakan cell-based architecture?
Ketika skala tenant dan biaya kegagalan rendah, atau konsistensi kuat lintas-tenant mendominasi, duplikasi sumber daya dan kompleksitas migrasi mungkin tidak sebanding dengan hasilnya.
Bagaimana cell dapat berbagi identitas dan penagihan (billing)?
Pertahankan layanan bersama dalam control plane berkecepatan rendah, cache hasil read-only, dan tentukan mode degradasi. Penulisan penagihan memerlukan kunci idempotensi dan kompensasi agar gangguan pada layanan bersama tidak menyebar ke setiap data plane.