Wawancara data engineering: Bagaimana cara membuat DynamoDB TransactWriteItems idempoten?

Petunjuk dan konteks

Layanan pesanan harus membuat pesanan, mengurangi inventaris, dan menulis entri buku besar dalam satu operasi bisnis. Batas waktu jaringan dapat terjadi setelah DynamoDB melakukan komit, sehingga klien dapat mengirim permintaan lagi. Gunakan TransactWriteItems untuk merancang penulisan atomik, kondisi, percobaan ulang idempoten, dan rekonsiliasi, termasuk biaya kapasitas dan batas regional.

Hal yang dievaluasi oleh pewawancara

• Apakah Anda membedakan komit atomik, kegagalan bersyarat, dan hasil yang tidak diketahui setelah pemutusan jaringan.
• Apakah Anda menggunakan ClientRequestToken, kunci idempotensi bisnis yang tahan lama (durable), dan ekspresi kondisi dengan benar.
• Apakah Anda memperhitungkan kapasitas transaksional tambahan, batas API, dan perebutan kunci panas (hot-key contention).
• Apakah percobaan ulang, kompensasi, rekonsiliasi, metrik, dan konsistensi lintas wilayah membentuk satu desain yang utuh.

Pertanyaan klarifikasi

1. Apakah tabel pesanan, inventaris, dan buku besar berada di AWS Region dan batas akun yang sama?
2. Apakah penjualan berlebih (overselling) diizinkan, dan apakah buku besar harus berupa catatan append-only yang tidak dapat diubah?
3. Bisakah klien menanyakan status akhir menggunakan kunci idempotensi bisnis setelah timeout?
4. Mungkinkah percobaan ulang terjadi setelah jendela validitas token berakhir?
5. Apakah penulisan pemulihan bencana lintas wilayah diperlukan, atau apakah atomisitas wilayah tunggal sudah cukup?

Jawaban 30 detik

Saya akan membuat kunci idempotensi yang stabil untuk setiap operasi bisnis dan menggunakan TransactWriteItems di satu Region untuk membuat pesanan, mengurangi inventaris secara kondisional, dan menulis entri buku besar secara atomik. Permintaan membawa ClientRequestToken; status bisnis yang tahan lama dan kondisi mencegah pengurangan ganda. Setelah timeout, baca berdasarkan kunci bisnis sebelum mencoba lagi. Pantau konflik, kegagalan bersyarat, kapasitas, dan hasil yang tidak diketahui. Untuk pekerjaan lintas wilayah, gunakan peristiwa dan rekonsiliasi karena batas atomik transaksi bersifat regional.

Jawaban mendalam

Langkah 1: Nyatakan invarian bisnis

Nyatakan invarian: pesanan yang berhasil mengurangi inventaris satu kali dan membuat satu entri buku besar. Gunakan satu operationId untuk catatan pesanan dan buku besar, serta wajibkan available >= quantity pada item inventaris. Jangan gunakan stempel waktu klien sebagai satu-satunya kunci; percobaan ulang dan perbedaan jam (clock skew) dapat menciptakan operasi duplikat.

Langkah 2: Susun tindakan transaksi

Gabungkan tindakan Put, Update, Delete, dan ConditionCheck dalam satu permintaan TransactWriteItems. Tindakan Put pesanan memerlukan kunci yang belum ada, Update inventaris memeriksa versi atau jumlah yang tersedia, dan Put buku besar menggunakan operationId sebagai kunci unik. Jangan beroperasi pada item yang sama dua kali dalam satu transaksi, dan patuhi batas tindakan serta batas ukuran permintaan.

Langkah 3: Bangun dua lapisan idempotensi

ClientRequestToken membuat permintaan transaksi yang sama dapat dicoba ulang dengan aman selama jendela validitasnya. Kunci idempotensi bisnis yang disimpan secara persisten dalam pesanan dan buku besar mencakup siklus hidup yang lebih lama. Keduanya harus mengidentifikasi operasi yang sama; percobaan ulang tidak boleh membuat kunci bisnis baru. Setelah jendela token berakhir, baca status bisnis sebelum menyusun ulang transaksi.

Langkah 4: Pisahkan kegagalan dari hasil yang tidak diketahui

Konflik bersyarat, kesalahan kapasitas, dan kegagalan validasi biasanya menyediakan jalur kegagalan yang dapat ditindaklanjuti: kembalikan kesalahan bisnis atau coba lagi dengan backoff terbatas sesuai dengan kesalahan tersebut. Koneksi yang terputus setelah pengiriman tidak diketahui hasilnya; jangan langsung membalikkan inventaris. Baca pesanan, versi inventaris, dan buku besar berdasarkan operationId, lalu biarkan state machine memilih percobaan ulang atau rekonsiliasi.

Langkah 5: Perhitungkan biaya dan hot key

DynamoDB melakukan pembacaan atau penulisan mendasar untuk persiapan dan komit transaksi, sehingga penggunaan kapasitas lebih tinggi daripada penulisan biasa tunggal. Perkirakan throughput dari ukuran item, konkurensi, dan amplifikasi percobaan ulang, serta lakukan sharding pada inventaris yang panas atau gunakan antrean reservasi. Rata-rata WCU tidak cukup; kegagalan bersyarat dan konflik juga menghabiskan anggaran latensi dan kapasitas.

Langkah 6: Tangani persyaratan regional

Atomisitas transaksi berlaku untuk batas transaksi di Region pemanggil. Jika analitik atau replika berada di tempat lain, publikasikan peristiwa yang membawa operationId; konsumen menulis secara idempoten dan rekonsiliasi menemukan celah atau duplikasi. Selama jeda replikasi (replication lag), model baca jarak jauh bukanlah bukti komit transaksi langsung.

Langkah 7: Observasi dan pemulihan

Catat keberhasilan transaksi, kegagalan bersyarat, konflik, throttling, jumlah percobaan ulang, hasil yang tidak diketahui, kapasitas per tabel, dan latensi ujung-ke-ujung. Gunakan status seperti PENDING, COMMITTED, RECONCILING, dan FAILED; pemindai menangani status yang tidak diketahui dan menyelesaikan buku besar atau membuat antrean penanganan manual. Hubungkan log permintaan, item tabel, dan peristiwa berdasarkan operationId.

Jawaban model

Untuk setiap pesanan, saya akan membuat operationId yang stabil dan menggunakan TransactWriteItems di satu Region untuk membuat pesanan, mengurangi inventaris secara kondisional, dan menulis item buku besar dengan kunci ID tersebut. Pesanan memerlukan kunci yang belum ada, inventaris memeriksa versinya dan available >= quantity, dan buku besar secara alami dideduplikasi. Permintaan ini juga membawa ClientRequestToken yang stabil. Kegagalan bersyarat mengembalikan kesalahan bisnis yang dapat dijelaskan; timeout setelah komit pertama-tama membaca ketiga catatan berdasarkan operationId alih-alih secara membabi buta membalikkan inventaris. Estimasi kapasitas mencakup pekerjaan persiapan dan komit transaksional, hot key, serta amplifikasi percobaan ulang. Propagasi lintas wilayah menggunakan peristiwa idempoten dan rekonsiliasi daripada mengklaim atomisitas lintas wilayah. Metrik mencakup konflik, kapasitas, hasil yang tidak diketahui, dan waktu pemulihan state machine.

Kesalahan umum

• Memperlakukan batas waktu (timeout) sebagai bukti bahwa transaksi gagal dan langsung membalikkan inventaris.
• Menghasilkan kunci bisnis baru pada setiap percobaan ulang, sehingga menciptakan pesanan atau entri buku besar duplikat.
• Hanya bergantung pada ClientRequestToken dan mengabaikan idempotensi bisnis yang tahan lama.
• Mengabaikan konflik bersyarat, batas transaksi, dan kapasitas transaksional tambahan.
• Menganggap replikasi tabel global atau pembacaan jarak jauh sebagai bukti komit transaksi.
• Tidak memiliki pemindai status yang tidak diketahui atau jalur rekonsiliasi selain pemeriksaan log manual.

Pertanyaan lanjutan

Pertanyaan lanjutan 1: Apakah ClientRequestToken menjamin idempotensi permanen?

Tidak. Ini hanya mencakup jendela validitas yang ditentukan API. Idempotensi jangka panjang memerlukan kunci bisnis dan status akhir dalam pesanan, buku besar, atau tabel operasi.

Pertanyaan lanjutan 2: Haruskah kegagalan kondisi inventaris dicoba lagi?

Jika inventaris tidak mencukupi, mencoba lagi tidak dapat mengubah hasil dan harus mengembalikan kegagalan bisnis. Konflik sementara atau pembatasan (throttling) dapat dicoba lagi dengan backoff, kunci operasi yang sama, dan batas jumlah percobaan yang terukur.

Pertanyaan lanjutan 3: Bagaimana Anda memutuskan hasilnya setelah timeout?

Baca pesanan, versi inventaris, dan buku besar berdasarkan operationId. Catatan yang konsisten menunjukkan komit; visibilitas parsial atau ketidaksesuaian masuk ke RECONCILING, di mana alur kerja memilih penyelesaian atau penanganan manual.

Pertanyaan lanjutan 4: Mengapa tidak menempatkan penulisan lintas wilayah dalam satu transaksi?

API tidak memperluas atomisitas ke berbagai Region. Gunakan peristiwa, konsumen idempoten, dan rekonsiliasi sambil mendokumentasikan jendela konsistensi akhir (eventual consistency) dan perilaku degradasi.

Pertanyaan lanjutan 5: Bagaimana Anda menemukan konflik transaksi?

Catat operationId, kunci item, versi kondisi, dan jumlah percobaan ulang, lalu agregasikan konflik berdasarkan hot key. Item inventaris yang mengalami perebutan terus-menerus mungkin memerlukan sharding, reservasi, atau alokasi berbasis antrean.

Pertanyaan lanjutan 6: Bagaimana Anda menguji jalur hasil yang tidak diketahui?

Hentikan (drop) respons setelah server mengonfirmasi komit untuk menyimulasikan batas waktu klien. Verifikasi pencarian, percobaan ulang, transisi status, deduplikasi peristiwa, dan rekonsiliasi sehingga inventaris dan buku besar tidak pernah diterapkan dua kali.