DynamoDB Streams

DynamoDB Streams adalah log change-data-capture: setiap insert, update, dan delete pada sebuah tabel ditangkap, secara berurutan, sebagai aliran record yang dapat Anda reaksi. Inilah cara Anda mengubah sebuah tabel menjadi event source tanpa polling.

Dalam skenario audit-log Anda ingin bereaksi pada saat sebuah event sensitif mendarat — memicu peringatan saat seseorang mengekspor invoice atau memberikan peran admin — tanpa men-scan tabel pada timer. Streams adalah sisi push dari itu.

Bagaimana cara kerja DynamoDB Streams?

DynamoDB Streams menangkap setiap insert, update, dan delete pada sebuah tabel sebagai log record yang terurut waktu dan terdeduplikasi, disimpan hingga 24 jam. Anda memilih apa yang dibawa setiap record melalui StreamViewType (hanya key, image baru, image lama, atau keduanya), lalu mengonsumsi stream dengan trigger Lambda untuk bereaksi terhadap perubahan Item tanpa polling.

• Streams menangkap perubahan tingkat Item sebagai log yang terurut waktu dan terdeduplikasi, disimpan hingga 24 jam.
• Anda memilih apa yang dibawa setiap record melalui StreamViewType: hanya key, image baru, image lama, atau keduanya lama dan baru.
• Record terurut di dalam sebuah partition key, dan sebuah stream di-shard dengan cara yang sama seperti tabel.
• Consumer nativenya adalah Lambda — sebuah trigger yang berjalan per batch record baru, dengan Kinesis Data Streams sebagai alternatif untuk fan-out yang lebih kaya.

Masalahnya: bereaksi tanpa polling

Anda butuh "beri tahu saya saat sebuah event role.granted ditulis." Pendekatan naif adalah sebuah job terjadwal yang men-scan event baru setiap menit — yang membaca seluruh partisi terakhir setiap kali, berbiaya kapasitas, dan selalu terlambat setidaknya satu menit.

Yang sebenarnya Anda inginkan adalah push: DynamoDB memberi tahu Anda saat sebuah Item berubah. Itulah persis yang disediakan Streams, dengan record perubahan dikirim ke kode Anda alih-alih Anda memburunya.

Cara kerja Streams

Menurut dokumentasi AWS, DynamoDB Streams menyimpan "log perubahan yang terdeduplikasi dan terurut waktu selama hingga 24 jam" dengan integrasi Lambda native (change data capture for DynamoDB). Setiap record menggambarkan satu modifikasi tingkat Item.

Saat Anda mengaktifkan sebuah stream Anda memilih sebuah StreamViewType, yang mengontrol seberapa banyak dari Item yang berubah yang dibawa setiap record:

Record terurut di dalam setiap partition key dan stream di-shard sepanjang struktur partisi yang sama seperti tabel. Retensi adalah 24 jam — Streams adalah buffer reaksi, bukan riwayat permanen. Untuk riwayat tahan lama Anda menyimpan event-nya sendiri (yang persis seperti tabel audit-log kita sudah).

Consumer nativenya adalah sebuah Lambda trigger: DynamoDB memanggil fungsi Anda dengan sebatch record stream baru saat mereka tiba.

Contoh terkerjakan: peringatan pada event audit sensitif

Tabel audit-log mendapat sebuah stream dengan NEW_IMAGE, jadi setiap record membawa event baru yang penuh. Sebuah Lambda mengonsumsi batch dan meneruskan hanya record yang penting:

Fungsi tidak pernah menyentuh tabel — ia bereaksi murni terhadap apa yang diserahkan stream kepadanya. Tanpa polling, tanpa scan, dan peringatan memicu dalam hitungan detik dari penulisan. Karena record terurut per partition key, semua event satu tenant tiba dalam urutan saat mereka ditulis.

Ini juga cara standar untuk memelihara salinan downstream: sebuah stream consumer dapat memproyeksikan setiap event ke OpenSearch untuk pencarian audit teks-penuh, atau mengagregasi hitungan — semuanya diturunkan dari log perubahan yang sama.

Lakukan di DynoTable

Sebelum Anda merangkai sebuah stream consumer, Anda perlu tahu bentuk persis Item yang akan diterima Lambda Anda — atribut mana yang ada, bagaimana map dan list bersarang terlihat, apa yang sebenarnya akan dikandung sebuah record NEW_IMAGE.

Untuk mengonversi Item sampel antara JSON biasa dan bentuk attribute-value yang digunakan record stream, Konverter DynamoDB JSON melakukannya di browser Anda. Dan di DynoTable, Anda bisa memeriksa Item penuh — termasuk bentuk DynamoDB-JSON-nya — sehingga Anda memodelkan record NEW_IMAGE terhadap data nyata alih-alih menebak bentuk field-nya.

Jika Anda menguji sebuah consumer secara lokal, jalankan tabel terhadap DynamoDB Local dan periksa dengan cara yang sama — lihat terhubung ke DynamoDB Local.

Jebakan dan langkah berikutnya

• 24 jam bukan backlog. Jika consumer Anda mati selama sehari, record menua dan hilang. Streams untuk reaksi mendekati real-time, bukan replay tahan lama — simpan event-nya sendiri untuk riwayat.
• Pilih StreamViewType terkecil yang Anda butuhkan. NEW_AND_OLD_IMAGES menggandakan payload; jika Anda hanya butuh key untuk membaca ulang Item, KEYS_ONLY lebih murah.
• Pengurutan per partition key, bukan global. Event untuk dua tenant berbeda tidak punya jaminan pengurutan di antara mereka — hanya di dalam partisi satu tenant.
• Penghapusan TTL muncul sebagai record stream dengan penanda atribut sistem, yang merupakan cara Anda mengarsipkan Item yang kedaluwarsa — lihat DynamoDB TTL.

Streams mengubah audit log menjadi event source. Perhatian operasional berikutnya adalah ujung berlawanan dari hidup sebuah Item — mengakhiri event lama secara otomatis dengan DynamoDB TTL.

Unduh DynoTable untuk memeriksa bentuk Item persis yang akan diterima stream consumer Anda sebelum Anda menulis sebaris kode Lambda.