Petunjuk dan konteks
Layanan pesanan, preferensi, atau inventaris harus menawarkan operasi baca dan tulis lokal di beberapa Region. Bandingkan DynamoDB Global Tables MREC (multi-Region eventual consistency) dengan MRSC (multi-Region strong consistency), dan jelaskan perutean, konflik, failover, kapasitas, serta pemulihan. Wawancara ini menguji batas-batas konsistensi dan operasional, bukan sekadar menyalin basis data ke lokasi lain.
Global Tables adalah replikasi multi-Region, multi-aktif terkelola: replika mana pun dapat melayani operasi baca dan tulis. MREC adalah bawaan (default) dan mereplikasi secara asinkron; ketika item yang sama dimodifikasi hampir bersamaan di Region yang berbeda, DynamoDB menyelesaikannya pada granularitas item dengan aturan internal-timestamp last-writer-wins (LWW). MRSC mereplikasi secara sinkron ke setidaknya satu Region lain sebelum mengonfirmasi penulisan, dan pembacaan yang sangat konsisten (strongly consistent reads) pada replika mana pun mengembalikan nilai terbaru; ini membutuhkan tepat tiga Region (tiga replika, atau dua replika ditambah satu witness).
Apa yang sedang diuji oleh pewawancara
Jawaban yang kuat membedah invarian bisnis menjadi item, partition key, dan transaksi lintas-item sebelum memilih mode berdasarkan RPO, latensi tulis, dan jaminan baca. Bersiaplah menghadapi pertanyaan tentang kehilangan data secara senyap (silent loss) di bawah LWW, batasan tiga Region pada MRSC, visibilitas transaksi MREC lintas-Region, dan pengurutan selama failback.
Hanya mengatakan “aktifkan replikasi multi-Region” tidaklah cukup. Jelaskan endpoint Region lokal, cara menghindari penulisan ganda (dual writes) ke satu item, cara memantau ReplicationLatency, dan cara menangani penghapusan, percobaan ulang (retry), serta peristiwa duplikat.
Pertanyaan untuk diklarifikasi terlebih dahulu
Invarian dan bentuk konflik
Tanyakan apakah status pesanan boleh bergerak mundur, apakah inventaris harus linearizable, dan apakah satu item dapat diedit secara bersamaan di beberapa Region. Bidang yang dapat digabungkan secara independen dapat berupa item terpisah atau subrekaman berversi. Atomisitas lintas-bidang mengharuskan pemahaman bahwa transaksi MREC hanya atomik di Region pemanggil dan tidak direplikasi sebagai satu transaksi tunggal.
RPO, latensi, dan jumlah Region
Klarifikasi RPO, latensi tulis P99, waktu failover, dan Region yang patuh. MREC dapat menggunakan berapa pun jumlah Region yang tersedia dan biasanya menyebar dalam hitungan detik; MRSC mengorbankan sebagian latensi tulis demi pembacaan kuat lintas-Region dan target zero-RPO, sambil mewajibkan tepat tiga Region.
Kepemilikan penulisan dan pemulihan
Tentukan apakah penulisan benar-benar multi-aktif atau setiap penyewa (tenant) memiliki Region asal (home Region) dengan replika baca di tempat lain. Jika bisnis tidak dapat menerima LWW, gunakan IAM atau perutean untuk membatasi penulis dan tentukan otoritas untuk keputusan konflik selama pemulihan daripada mendelegasikan semantik ke replikasi.
Jawaban 30 detik
“Saya memilih mode berdasarkan invarian bisnis: pengurangan inventaris dan pembacaan kuat lintas-Region mengarah ke MRSC, sedangkan beban kerja yang menoleransi data basi sesaat dan memprioritaskan latensi tulis lokal menggunakan MREC bawaan. MREC bersifat asinkron dan LWW tingkat item, jadi saya menempatkan setiap pesanan atau penyewa ke satu Region asal dan menambahkan conditional writes, kunci idempotensi, dan versi eksplisit; status yang tidak dapat digabungkan tidak mengandalkan LWW. Setiap permintaan menggunakan endpoint lokalnya, dan lalu lintas dipindahkan di edge aplikasi selama terjadi kegagalan regional. Saya memantau ReplicationLatency, kesalahan replikasi, dan kegagalan conditional-write, lalu memutar ulang (replay) serta mengaudit pemulihan menggunakan versi, peristiwa, dan aturan bisnis.”
Solusi langkah demi langkah
Langkah 1: Pilih mode konsistensi
MREC adalah bawaan, mendukung berapa pun jumlah Region, dan bersifat konsisten pada akhirnya (eventually consistent), cocok untuk preferensi, katalog, dan model baca yang toleran terhadap data basi. MRSC secara sinkron mereplikasi penulisan ke setidaknya satu Region lain sebelum berhasil; pembacaan kuat pada replika mana pun melihat nilai terbaru. Ini membutuhkan tepat tiga Region dan tidak mendukung operasi transaksi. Mode dipilih saat pembuatan: replika tidak dapat mencampur mode dan tabel tidak dapat diubah modenya di kemudian hari.
Langkah 2: Tentukan topologi penulisan
Aplikasi harus menggunakan endpoint DynamoDB di Region lokal mereka. Penulisan multi-aktif hanya tepat jika bisnis dapat menyelesaikan konflik yang terjadi bersamaan. Objek yang dibatasi secara ketat seperti pesanan dan inventaris dapat menggunakan penulisan di Region asal dengan pembacaan di tempat lain, atau partisi penulis tunggal (single-writer) berdasarkan penyewa atau pesanan. Panggilan lintas-Region menambah latensi dan bidang kegagalan; pengalihan lalu lintas adalah bagian dari titik masuk aplikasi atau lapisan perutean.
Langkah 3: Batasi konflik di bawah MREC
MREC menggunakan LWW dengan timestamp internal untuk pembaruan yang hampir bersamaan pada satu item. Replika akan konvergen, tetapi perubahan bisnis yang dibuang tidak otomatis menjadi pekerjaan kompensasi. Gunakan condition expressions untuk versi dan sertakan ID permintaan yang idempoten. Simpan peristiwa append-only atau catatan konflik untuk status yang tidak boleh ditimpa. Representasikan penghapusan dengan tombstone atau status eksplisit sehingga pembaruan basi tidak dapat membangkitkan kembali objek yang telah dihapus.
Langkah 4: Tangani transaksi dan percobaan ulang
Pada MREC, TransactWriteItems bersifat atomik hanya di Region pemanggil; replika lain dapat mengamati efek parsial untuk sementara, sehingga pembacaan lintas-Region bukan merupakan konfirmasi transaksi. Percobaan ulang harus membedakan kegagalan kondisional, pembatasan laju (throttling), dan keterlambatan replikasi, dengan bounded exponential backoff dan kunci idempotensi. MRSC tidak mendukung operasi transaksi, sehingga invarian lintas-item memerlukan model baru atau koordinasi tingkat layanan.
Langkah 5: Rencanakan failover dan pemulihan
Pantau latensi replikasi, kesalahan replikasi, kegagalan conditional-write, Region permintaan, dan versi bisnis. Selama isolasi, pindahkan lalu lintas masuk ke Region yang sehat. Dengan MREC, pertama-tama jeda penulisan yang sensitif terhadap konflik atau tetapkan ulang Region asal penyewa, catat waktu cutover dan versi terakhir yang terlihat. Setelah pemulihan, validasi konvergensi dengan log peristiwa, versi, dan aturan bisnis; replika yang identik saja tidak membuktikan inventaris atau pesanan yang benar.
Langkah 6: Kapasitas, keamanan, dan tata kelola
Nilai kapasitas baca/tulis, penskalaan otomatis, dan kuota untuk setiap replika. Replika baru mewarisi pengaturan kapasitas Region sumber saat pembuatan dan dapat disesuaikan setelahnya. Aktifkan perlindungan penghapusan per replika, gunakan IAM untuk membatasi Region penulis dan operasi tabel, dan ingat bahwa kehilangan izin KMS akan menghentikan replikasi terkait. Global Tables multi-akun mendukung MREC, bukan MRSC, sehingga kepemilikan akun, Region, dan audit harus eksplisit.
Langkah 7: Verifikasi dan lakukan gladi bersih
Latih penulisan bersamaan ke satu item di dua Region, percobaan ulang kondisional, partisi jaringan, penghapusan dengan pembaruan yang terlambat, lonjakan replikasi, cutover lalu lintas, dan failback. Verifikasi konvergensi akhir, kelengkapan peristiwa kompensasi, dan pemutaran ulang yang aman dari duplikasi, korelasikan ReplicationLatency dan jumlah konflik dengan ID permintaan. Uji beban harus mencerminkan jarak Region dan mode kapasitas yang sebenarnya; latensi mesin tunggal bukanlah estimasi lintas-Region.
Contoh jawaban berkualitas tinggi
Saya memilih mode berdasarkan invarian. Data kritis yang memerlukan pembacaan kuat lintas-Region dan target zero-RPO dapat menggunakan MRSC, menerima batasan tepat tiga Region, latensi tulis yang lebih tinggi, dan ketiadaan operasi transaksi. Katalog dan preferensi dapat menggunakan MREC. Karena LWW tingkat item yang asinkron tidak dapat menggabungkan semantik bisnis, pesanan dan inventaris menggunakan penulisan tunggal di Region asal penyewa atau pesanan, condition expressions, versi, dan kunci idempotensi. Bidang yang dapat digabungkan dipisahkan menjadi item tersendiri; pembaruan yang tidak dapat digabungkan menjadi peristiwa konflik.
Aplikasi menggunakan endpoint lokal dan lapisan masuk melakukan failover regional. Saya memantau ReplicationLatency, kegagalan replikasi dan conditional-write, serta perbedaan versi, dengan backoff terikat untuk throttling dan keterlambatan. Selama pemulihan, saya membekukan penulisan yang terpengaruh, memvalidasi konvergensi dari log peristiwa dan aturan bisnis, lalu membuka kembali lalu lintas secara bertahap. Saya mengaudit kapasitas, perlindungan penghapusan, IAM, dan KMS per replika serta melatih penulisan bersamaan, partisi, penghapusan terlambat, dan pemutaran ulang duplikat.
Kesalahan umum
- Kesalahan: Menganggap Global Tables berarti penulisan multi-aktif tanpa batas. → Mengapa gagal: LWW pada MREC dapat membuang perubahan bisnis yang tidak dapat digabungkan. → Solusi: Tetapkan kepemilikan tulis atau rancang versi eksplisit, peristiwa, dan kompensasi.
- Kesalahan: Memperlakukan transaksi MREC sebagai atomik secara global. → Mengapa gagal: Atomisitas bersifat lokal untuk Region pemanggil dan replika lain dapat melihat efek parsial. → Solusi: Modelkan ulang invarian lintas-Region dan koordinasikan dengan peristiwa serta idempotensi.
- Kesalahan: Beralih Region secara membabi buta setelah batas waktu (timeout). → Mengapa gagal: Penulisan ganda memperbesar konflik dan risiko saat failback. → Solusi: Jeda atau batasi penulisan, catat versi, lalu alihkan berdasarkan batas penyewa atau bisnis.
- Kesalahan: Menyamakan konvergensi replika dengan inventaris yang benar. → Mengapa gagal: LWW menyelesaikan replikasi, bukan arti bisnis. → Solusi: Validasi dengan conditional writes, log peristiwa, kompensasi, dan audit.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Kapan Anda akan memilih MRSC?
Pilih MRSC ketika pembacaan kuat lintas-Region dan target zero-RPO lebih penting daripada latensi tulis dan fleksibilitas Region. Ini membutuhkan tepat tiga Region, secara opsional satu witness, dan tidak mendukung transaksi. Jika beban kerja memerlukan jumlah replika arbitrer atau replikasi multi-akun, evaluasi ulang MREC dan koordinasi tingkat layanan.
Pertanyaan lanjutan 2: Bagaimana jika LWW menimpa pengurangan inventaris?
Jangan memulihkan kuantitas dari LWW. Gunakan condition expression dan versi untuk pengurangan tersebut, tetapkan pemilik tulis yang stabil berdasarkan produk atau shard inventaris, dan catat setiap pengurangan sebagai peristiwa idempoten. Detektor konflik membandingkan urutan peristiwa dan mengeluarkan kompensasi atau antrean penanganan manual; operasi baca memeriksa versi dan waktu visibilitas.
Pertanyaan lanjutan 3: Apa yang Anda lakukan saat lag replikasi MREC meningkat?
Kelompokkan peringatan berdasarkan Region sumber, Region tujuan, dan dampak bisnis. Batasi penulisan lintas-Region atau kembalikan penyewa ke Region asal mereka untuk berhenti menciptakan konflik. Batasi percobaan ulang klien, lalu rekonsiliasi versi, peristiwa terlambat, dan penanda hapus sebelum memulihkan penulisan multi-aktif. ReplicationLatency mengukur penyebaran, bukan kebenaran bisnis.
Pertanyaan lanjutan 4: Bagaimana cara Anda menguji failback?
Latih cutover lalu lintas, pemulihan Region lama, permintaan yang tiba di kedua sisi, dan penghapusan yang terlambat. Catat Region, versi, dan ID idempotensi untuk setiap permintaan. Verifikasi bahwa Region lama tidak dapat menimpa status yang lebih baru, peristiwa konflik tetap dapat dilacak, dan kompensasi dapat diulang. Laporkan RPO, RTO, jumlah konflik, dan intervensi manual.
Pertanyaan lanjutan 5: Mengapa replika tidak dapat mencampur MREC dan MRSC?
Mode konsistensi adalah pengaturan tingkat tabel saat pembuatan: replika tidak dapat menggunakan mode yang berbeda dan tabel tidak dapat diubah setelah dibuat. Perubahan persyaratan memerlukan tabel baru, migrasi, dan jendela penulisan ganda atau pemutaran ulang yang terkontrol, dengan kapasitas, izin, kompatibilitas klien, dan rencana rollback yang divalidasi terlebih dahulu.