Konteks dan cakupan
Sebuah SaaS multi-region menampilkan status pesanan, saldo akun, notifikasi yang belum dibaca, dan analitik. Tim rekayasa mengusulkan eventual consistency di semua tempat untuk menurunkan latensi dan biaya, sementara tim keuangan mewajibkan saldo harus langsung akurat seketika. Pilih pembacaan strong, eventual, atau bounded-staleness berdasarkan user journey, lalu tentukan janji produk, SLO, kondisi terdegradasi (degraded states), dan release gates.
Ini menguji apakah seorang product manager dapat menerjemahkan semantik sistem terdistribusi ke dalam kebijakan produk yang terukur. AWS DynamoDB menyediakan pembacaan eventual dan strong, sementara Google Cloud Spanner menyediakan external consistency dan pembacaan stale yang terkontrol; keputusan bergantung pada journey baca/tulis, bukan sekadar slogan.
Hal yang diuji oleh pewawancara
- Apakah Anda melakukan segmentasi berdasarkan tindakan pengguna dan risiko alih-alih mengikat seluruh produk pada satu mode.
- Apakah Anda mendefinisikan "terbaru", read-after-write, cross-region, dan visibilitas kegagalan.
- Apakah pilihan konsistensi terhubung dengan metrik latensi, kapasitas, biaya, pendapatan, dan kepercayaan.
- Apakah Anda merancang teks saat sistem terdegradasi, penanganan sengketa, eksperimen, dan peluncuran yang dapat dibatalkan (reversible rollout).
Pertanyaan klarifikasi awal
- Data mana yang memengaruhi penagihan, saldo, inventaris, atau kepatuhan (compliance), dan berapa kerugian dari periode data usang (stale window)?
- Apakah pengguna baru saja menulis data dan berharap dapat membaca data yang baru ditulisnya? Berapa tingkat keusangan yang dapat diterima?
- Wilayah (region) mana saja yang mereplikasi data, dan apakah mode kegagalan dapat berupa read-only, diantrekan, atau disembunyikan?
- Berapa baseline latensi, kapasitas, dan biaya saat ini untuk pembacaan strong dan eventual?
- Bisakah produk menampilkan status pemrosesan, waktu pembaruan terakhir, konflik, atau percobaan ulang alih-alih berpura-pura memberikan kepastian?
Kerangka jawaban 30 detik
Klasifikasikan journey dan tentukan SLO konsistensi. Konfirmasi pembayaran, perubahan saldo, dan reservasi inventaris memerlukan semantik strong atau batasan transaksi. Rekomendasi, jumlah yang belum dibaca, dan analitik dapat menggunakan pembacaan eventual atau bounded-staleness dengan batas usia data maksimum yang eksplisit. Untuk read-after-write, gunakan session stickiness, versi, atau endpoint konfirmasi. Tuliskan latensi, biaya, pengalaman error, dan metrik untuk setiap pilihan; terapkan canary pada jalur berisiko rendah dan lakukan rollback atau perkuat konsistensi saat batasan keamanan (guardrails) kepercayaan atau keuangan gagal.
Jawaban langkah demi langkah
1. Mulai dari tindakan, bukan produk database
Buat daftar tindakan seperti mengirimkan pembayaran, melihat saldo, mengedit profil, menjelajahi rekomendasi, dan membaca laporan. Tandai pihak yang menulis, pihak yang membaca, risiko, usia data yang dapat diterima, dan atomisitas lintas-entitas. Satu halaman dapat menggabungkan beberapa semantik; halaman tersebut tidak memerlukan tombol strong-read global.
2. Tulis janji yang dapat diverifikasi pengguna
Terjemahkan istilah teknis ke dalam bahasa yang dapat diamati: "Setelah konfirmasi pembayaran, halaman saldo menampilkan saldo baru dalam respons konfirmasi," atau "Analitik mungkin tertunda 15 menit dan menampilkan waktu datanya." Nyatakan perilaku saat terjadi kegagalan lintas wilayah; "data pada akhirnya akan konvergen" bukanlah janji langsung.
3. Pilih pembacaan strong, eventual, atau bounded-staleness
Pembacaan strong cocok untuk error dengan potensi kerugian tinggi, read-after-write, dan batasan transaksi. Pembacaan eventual cocok untuk konten yang dapat dicoba ulang, digabungkan (mergeable), berisiko rendah, atau memiliki beban baca tinggi. Bounded-staleness cocok untuk laporan yang menerima batas rentang waktu tertentu tetapi membutuhkan latensi yang stabil. AWS mendokumentasikan opsi strong reads untuk tabel DynamoDB dan indeks sekunder lokal, sementara indeks sekunder global dan streams bersifat eventually consistent; petakan batasan tersebut ke fitur, bukan ke nama produk.
4. Tangani read-after-write dan konflik
Kembalikan versi, token konfirmasi, atau waktu pembaruan setelah penulisan, dan kirimkan kondisi versi pada pembacaan berikutnya; arahkan rute ke region penulisan jika diperlukan. Penulisan bersamaan lintas wilayah (multi-region concurrent writes) memerlukan aturan penggabungan, peninjauan manusia, atau kondisi penolakan. "Last writer wins" bukanlah kebijakan produk untuk saldo kecuali kerugiannya dapat diterima.
5. Rancang pengalaman terdegradasi dan guardrails
Tampilkan status pemrosesan, waktu pembaruan terakhir, dan tindakan coba lagi. Jika saldo atau inventaris tidak pasti, jeda pembayaran, bekukan tindakan berikutnya, atau alihkan ke operator. Guardrails mencakup kesalahan penagihan, penjualan berlebih (oversell), keluhan, kegagalan read-after-write, latensi P95, usia replikasi, dan biaya. Pertahankan audit trail untuk setiap keputusan saat kondisi terdegradasi.
6. Uji coba canary, ukur, dan lakukan rollback
Lakukan canary pada penyewa (tenants) atau journey berisiko rendah dan bandingkan latensi, tingkat keberhasilan, distribusi keusangan, konversi, dan kontak dukungan. Jika keusangan melebihi SLO atau metrik kepercayaan dan keuangan memburuk, pulihkan pembacaan strong, persempit cakupan wilayah, atau jeda penulisan. External consistency dan stale reads pada Spanner membuktikan bahwa jaminan kuat dan versi lama yang terkontrol dapat hidup berdampingan; pilih berdasarkan journey daripada mengubahnya secara global.
Contoh jawaban berkualitas tinggi
Pertama-tama saya akan memetakan journey: pembayaran, saldo, dan inventaris adalah transaksi berisiko tinggi yang membutuhkan semantik strong atau batasan transaksi yang eksplisit. Rekomendasi, jumlah belum dibaca, dan analitik dapat menggunakan eventual, dengan usia data maksimum dan waktu pembaruan yang terlihat. Untuk kasus "simpan lalu langsung lihat", kembalikan versi atau token konfirmasi dan pertahankan sesi di region penulisan untuk jendela waktu yang singkat.
Teks pada produk akan menjanjikan apa yang dilihat pengguna, kapan mereka melihatnya, dan apa yang terjadi selama kegagalan wilayah. Setiap journey memiliki guardrails latensi, biaya, keusangan, tingkat error, dan kepercayaan. Saya akan menerapkan canary pada jalur berisiko rendah, memantau usia replikasi, kegagalan read-after-write, kesalahan tagihan atau oversell, dan kontak dukungan, lalu memulihkan pembacaan strong, menjeda penulisan berisiko, atau melakukan rollback ketika ambang batas terlanggar. Batasan per-permintaan DynamoDB dan opsi external-consistency/stale-read pada Spanner menunjukkan bahwa konsistensi adalah kombinasi kapabilitas, bukan sekadar satu tombol produk.
Kesalahan umum yang sering terjadi
- Mengatakan "strong di semua tempat adalah yang paling aman" atau "eventual di semua tempat adalah yang paling murah" tanpa segmentasi journey.
- Mendiskusikan latensi database tanpa mendefinisikan status yang terlihat oleh pengguna, usia data, dan teks saat terjadi kegagalan.
- Mengabaikan read-after-write, perutean region, dan konflik penulisan bersamaan.
- Memperlakukan eventual consistency sama untuk setiap indeks, stream, dan replika multi-region.
- Tidak memiliki guardrails untuk keuangan, inventaris, kepercayaan, biaya, atau rollback.
- Menjanjikan peningkatan persentase tetap tanpa baseline dan rancangan eksperimen.
Pertanyaan lanjutan dan jawaban referensi
Kapan eventual consistency dapat diterima?
Ketika rentang waktu data usang yang singkat tidak menimbulkan kerugian yang tidak dapat dipulihkan, pengguna dapat mencoba lagi atau menggabungkan data, serta halaman dapat menampilkan usia dan status data. Rekomendasi, jumlah belum dibaca, dan laporan non-kritis sering kali lebih cocok dibanding saldo.
Bagaimana cara mendefinisikan read-after-write sebagai SLO produk?
Setelah konfirmasi penulisan, pembacaan dalam rentang waktu dan cakupan wilayah yang ditentukan harus mengembalikan data yang setidaknya sama barunya dengan versi tersebut. Lacak tingkat kegagalan dan waktu tunggu maksimum, bukan hanya latensi rata-rata.
Mengapa tidak menggunakan pembacaan strong di setiap halaman?
Langkah tersebut dapat menambah latensi lintas wilayah, kapasitas, dan biaya, serta mengurangi ketersediaan (availability) saat terjadi kegagalan. Simpan semantik strong hanya untuk journey di mana faktor kepercayaan dan pencegahan kerugian membenarkan penggunaan sumber daya tersebut.
Bagaimana konflik eventual multi-region harus ditangani?
Tentukan field yang dapat digabungkan, kondisi versi, dan antrean peninjauan manusia untuk kasus yang belum terselesaikan per entitas. Untuk saldo yang tidak dapat digabungkan, tolak atau kunci alih-alih menimpanya secara diam-diam.
Bagaimana cara menjelaskan data yang usang kepada pengguna?
Tampilkan waktu data, status pemrosesan, dan tindakan muat ulang (refresh). Blokir pembayaran atau langkah berikutnya yang bergantung pada inventaris ketika kepastian sangat penting, dan sediakan jalur pemulihan yang jelas.
Kapan Anda harus beralih ke penyimpanan lain atau database dengan konsistensi kuat?
Ketika mode saat ini tidak dapat memenuhi kebutuhan read-after-write, atomisitas lintas-entitas, atau persyaratan audit pada biaya yang dapat diterima. Kuantifikasi kesenjangannya terlebih dahulu, lalu bandingkan pembacaan strong lokal, transaksi, perutean, dan migrasi.