Amazon DynamoDB Dijelaskan: Membangun Sistem Skalabel

Apa itu DynamoDB dan Mengapa Tim Memilihnya

Amazon DynamoDB adalah layanan basis data NoSQL yang dikelola penuh oleh AWS, dirancang untuk aplikasi yang membutuhkan pembacaan dan penulisan dengan latensi rendah yang konsisten pada hampir semua skala. “Dikelola penuh” berarti AWS menangani pekerjaan infrastruktur—penyediaan perangkat keras, replikasi, patching, dan banyak tugas operasional—sehingga tim bisa fokus mengirim fitur, bukan menjalankan server basis data.

Pada dasarnya, DynamoDB menyimpan data sebagai item (baris) di dalam tabel, tetapi setiap item dapat memiliki atribut yang fleksibel. Model data paling mudah dipahami sebagai gabungan dari:

• Key-value: ambil item dengan cepat menggunakan primary key, seperti mencari catatan berdasarkan ID.
• Document: menyimpan atribut bersarang (maps dan lists), mirip JSON, berguna untuk bidang terkait tanpa skema ketat.

Tim memilih DynamoDB ketika mereka menginginkan performa yang dapat diprediksi dan operasi yang lebih sederhana untuk beban kerja yang tidak cocok dengan join relasional. Ini umum dipakai untuk mikroservis (setiap layanan memiliki data sendiri), aplikasi serverless dengan trafik bursty, dan sistem event-driven yang bereaksi terhadap perubahan data.

Posting ini membahas blok bangunan (tabel, kunci, dan indeks), cara memodelkan berdasarkan pola akses (termasuk desain satu-tabel), bagaimana skala dan mode kapasitas bekerja, serta pola praktis untuk streaming perubahan ke arsitektur event-driven.

Konsep Inti: Tabel, Item, dan Kunci Primer

DynamoDB disusun di sekitar beberapa blok bangunan sederhana, tetapi detailnya penting karena menentukan cara Anda memodelkan data dan seberapa cepat (dan hemat biaya) permintaan akan dijalankan.

Tabel, item, dan atribut

Sebuah tabel adalah kontainer tingkat atas. Setiap catatan dalam tabel adalah sebuah item (mirip baris), dan setiap item adalah sekumpulan atribut (mirip kolom).

Tidak seperti basis data relasional, item dalam tabel yang sama tidak harus memiliki atribut yang sama. Satu item mungkin memiliki {status, total, customerId}, sementara item lain berisi {status, shipmentTracking}—DynamoDB tidak memerlukan skema tetap.

Kunci primer: sederhana vs komposit

Setiap item diidentifikasi secara unik oleh kunci primer, dan DynamoDB mendukung dua tipe:

• Kunci primer sederhana (hanya kunci partisi): satu atribut mengidentifikasi setiap item secara unik.
• Kunci primer komposit (kunci partisi + kunci urut): beberapa item dapat berbagi kunci partisi yang sama, sementara kunci urut membedakan mereka dan menentukan urutan di dalam partisi tersebut.

Dalam praktiknya, kunci komposit memungkinkan pola akses “terkelompok” seperti “semua pesanan untuk pelanggan, terbaru terlebih dahulu.”

Query vs. Scan (tingkat tinggi)

Query membaca item berdasarkan kunci primer (atau kunci indeks). Ia menargetkan kunci partisi tertentu dan bisa memfilter menurut rentang kunci urut—ini adalah jalur yang efisien dan disarankan.

Scan berjalan ke seluruh tabel (atau indeks) lalu memfilter. Mudah untuk memulai, tetapi biasanya lebih lambat dan lebih mahal pada skala besar.

Batasan yang perlu diingat

Beberapa kendala yang akan Anda temui:

• Ukuran item maksimal: 400 KB.
• Tipe atribut: skalar (string/number/binary/boolean/null), set, list, dan map.
• Atribut kunci harus skalar (tidak boleh list/map sebagai partition atau sort key).

Fundamental ini menentukan pola akses, pilihan indeks, dan karakteristik performa.

Model Data DynamoDB: Key-Value dan Document

DynamoDB sering digambarkan sebagai penyimpanan key-value sekaligus basis data dokumen. Itu akurat, tetapi penting memahami implikasinya dalam desain sehari-hari.

Akses key-value vs item bergaya dokumen

Intinya, Anda mengambil data dengan kunci. Berikan nilai primary key dan DynamoDB mengembalikan satu item. Lookup berbasis kunci inilah yang memberikan penyimpanan dengan latensi rendah yang dapat diprediksi untuk banyak beban kerja.

Pada saat yang sama, sebuah item bisa berisi atribut bersarang (maps dan lists), sehingga terasa seperti basis data dokumen: Anda dapat menyimpan payload terstruktur tanpa mendefinisikan skema kaku terlebih dahulu.

Memodelkan struktur hierarkis mirip JSON dalam item

Item cocok untuk data mirip JSON:

• Maps mewakili objek (mis. profile.name, profile.address).
• Lists mewakili array (mis. aksi terbaru, tag).

Ini pas ketika sebuah entitas biasanya dibaca secara keseluruhan—seperti profil pengguna, keranjang belanja, atau bundel konfigurasi.

Kapan harus menormalisasi ulang (denormalize) dan mengapa umum dilakukan

DynamoDB tidak mendukung join sisi server. Jika aplikasi Anda perlu mengambil “sebuah pesanan plus line items plus status pengiriman” dalam satu jalur baca, Anda sering kali akan denormalize: menyalin beberapa atribut ke beberapa item, atau menyertakan substruktur kecil langsung di dalam item.

Trade-off vs normalisasi relasional

Denormalisasi menambah kompleksitas tulis dan dapat menyebabkan fan-out pada pembaruan. Balasannya adalah lebih sedikit round trip dan pembacaan lebih cepat—seringkali ini adalah jalur kritis dalam sistem yang skalabel.

Kunci Partisi dan Kunci Urut: Mendesain untuk Pola Akses

Query DynamoDB tercepat adalah yang dapat Anda nyatakan sebagai “beri saya partisi ini” (dan opsional “dalam partisi ini, beri saya rentang ini”). Itu sebabnya pemilihan kunci pada dasarnya tentang bagaimana Anda membaca data, bukan hanya bagaimana menyimpannya.

Kunci partisi: distribusi dan pembacaan yang dapat diprediksi

Kunci partisi menentukan partisi fisik tempat item disimpan. DynamoDB melakukan hash terhadap nilai ini untuk menyebarkan data dan trafik. Jika banyak permintaan terkonsentrasi pada sejumlah kecil nilai kunci partisi, Anda bisa membuat partisi “panas” dan mencapai batas throughput meskipun tabel sebagian besar diam.

Kunci partisi yang baik:

• Memiliki kardinalitas tinggi (banyak nilai berbeda)
• Cocok dengan pola akses yang sering (sehingga pembacaan langsung, bukan memfilter)
• Menghindari nilai yang menjadi “populer” (mis. konstanta seperti "GLOBAL")

Kunci urut: kueri rentang dan pengelompokan entitas

Dengan kunci urut, item yang berbagi kunci partisi disimpan bersama dan diurutkan oleh kunci urut. Ini memungkinkan:

• Kueri rentang (BETWEEN, begins_with)
• Pembacaan terurut berdasarkan waktu (terbaru terlebih dahulu dengan reverse scan)
• Pengelompokan entitas (beberapa tipe item di bawah satu kunci partisi)

Pola umum adalah menyusun kunci urut, misalnya TYPE#id atau TS#2025-12-22T10:00:00Z, untuk mendukung beberapa bentuk kueri tanpa tabel tambahan.

Memetakan pola akses umum ke kunci

• Get by ID: PK = USER#<id> (simple GetItem)
• List by user: PK = USER#<id>, SK begins_with ORDER# (atau SK = CREATED_AT#...)
• Time-series ranges: PK = DEVICE#<id>, SK = TS#<timestamp> dengan BETWEEN untuk jendela waktu

Bagaimana pilihan kunci memengaruhi performa dan skalabilitas

Jika kunci partisi Anda selaras dengan kueri bernilai tinggi dan terdistribusi merata, Anda akan mendapatkan pembacaan dan penulisan dengan latensi rendah yang konsisten. Jika tidak, Anda akan mengkompensasi dengan scan, filter, atau indeks tambahan—masing-masing menambah biaya dan meningkatkan risiko kunci panas.

Indeks Sekunder: Penjelasan GSI dan LSI

Indeks sekunder memberi DynamoDB jalur kueri alternatif selain primary key tabel. Daripada mengubah tabel dasar setiap kali muncul pola akses baru, Anda dapat menambahkan indeks yang membuat kunci ulang item yang sama untuk kueri berbeda.

GSI vs LSI: apa bedanya?

Global Secondary Index (GSI) memiliki kunci partisi sendiri (dan opsi kunci urut) yang bisa benar-benar berbeda dari tabel utama. Ia bersifat “global” karena melintasi semua partisi tabel dan dapat ditambahkan atau dihapus kapan pun. Gunakan GSI ketika Anda membutuhkan pola akses baru yang tidak cocok dengan desain kunci asli—mis. mengkueri pesanan berdasarkan customerId ketika tabel diindeks berdasarkan orderId.

Local Secondary Index (LSI) berbagi kunci partisi yang sama dengan tabel dasar tetapi menggunakan kunci urut yang berbeda. LSI harus didefinisikan saat pembuatan tabel. Mereka berguna ketika Anda ingin beberapa urutan dalam grup entitas yang sama (kunci partisi sama), mis. mengambil pesanan pelanggan yang diurutkan berdasarkan createdAt versus status.

Proyeksi: apa yang disalin ke indeks

Proyeksi menentukan atribut mana yang disimpan oleh DynamoDB di indeks:

• KEYS_ONLY: penyimpanan paling murah, tetapi sering membutuhkan pembacaan tambahan dari tabel dasar.
• INCLUDE: salin hanya atribut yang sering dikembalikan.
• ALL: paling sederhana, tetapi dapat memperbesar penyimpanan dan biaya tulis.

Amplifikasi tulis (biaya tersembunyi)

Setiap tulis ke tabel dasar dapat memicu tulis ke satu atau beberapa indeks. Semakin banyak GSI dan semakin luas proyeksinya, semakin meningkat biaya tulis dan konsumsi kapasitas. Rencanakan indeks berdasarkan pola akses yang stabil, dan minimalkan atribut yang diproyeksikan bila memungkinkan.

Mode Kapasitas dan Perilaku Skala

Skalabilitas DynamoDB dimulai dengan pilihan: On-Demand atau Provisioned capacity. Keduanya bisa mencapai throughput tinggi, tetapi berperilaku berbeda saat lalu lintas berubah.

On-Demand vs Provisioned: bagaimana memilih

On-Demand paling sederhana: Anda membayar per permintaan dan DynamoDB secara otomatis mengakomodasi beban yang berubah-ubah. Cocok untuk lalu lintas yang tidak dapat diprediksi, produk tahap awal, dan beban bursty di mana Anda tidak ingin mengelola target kapasitas.

Provisioned adalah perencanaan kapasitas: Anda menentukan throughput baca dan tulis (atau mengatur auto-scale) dan mendapatkan harga yang lebih dapat diprediksi untuk penggunaan yang stabil. Seringkali lebih murah untuk beban yang konsisten dan untuk tim yang dapat memproyeksikan permintaan.

Kapasitas baca/tulis dalam praktik

Throughput provisioned diukur dengan:

• RCU (Read Capacity Unit): kira-kira satu pembacaan konsisten per detik untuk hingga 4 KB (atau dua pembacaan eventual konsisten).
• WCU (Write Capacity Unit): kira-kira satu penulisan per detik untuk hingga 1 KB.

Ukuran item dan pola akses menentukan biaya nyata: item lebih besar, konsistensi kuat, dan scan dapat menghabiskan kapasitas dengan cepat.

Dasar auto scaling (dan batasannya)

Auto scaling menyesuaikan RCUs/WCUs provisioned berdasarkan target pemanfaatan. Ini membantu pertumbuhan bertahap dan siklus yang dapat diprediksi, tetapi tidak instan. Lonjakan tiba-tiba masih dapat mengakibatkan throttling jika kapasitas tidak segera meningkat, dan auto scaling tidak memperbaiki kunci partisi panas yang memusatkan trafik.

DAX: caching untuk beban baca berat

DynamoDB Accelerator (DAX) adalah cache in-memory yang dapat mengurangi latensi baca dan mengurangi beban dari pembacaan berulang (mis. halaman produk populer, lookup session, leaderboard). Berguna ketika banyak klien meminta item yang sama berulang; tidak membantu pola write-heavy dan tidak menggantikan desain kunci yang baik.

Konsistensi, Transaksi, dan Kebenaran Data

DynamoDB memungkinkan Anda memilih jaminan baca terhadap latensi dan biaya, jadi penting untuk eksplisit tentang apa yang dimaksud dengan “benar” untuk setiap operasi.

Pembacaan eventual konsisten vs strongly consistent

Secara default, GetItem dan Query menggunakan pembacaan eventually consistent: Anda mungkin sesaat melihat nilai lama setelah penulisan. Ini sering cukup untuk feed, katalog produk, dan tampilan baca-dominan lainnya.

Dengan pembacaan strongly consistent (opsional untuk pembacaan dari tabel dasar dalam satu region), DynamoDB menjamin Anda melihat penulisan terakhir yang telah diakui. Konsistensi kuat menghabiskan lebih banyak kapasitas baca dan dapat meningkatkan tail latency, jadi gunakan untuk pembacaan yang benar-benar kritis.

Kapan konsistensi kuat penting

Konsistensi kuat berguna untuk pembacaan yang mengendalikan tindakan yang tidak dapat dibalikkan:

• Memeriksa inventaris yang tersedia sebelum mengonfirmasi pesanan
• Membaca flag otorisasi sebelum memberikan akses
• Mengambil status workflow saat ini sebelum menjalankan langkah berikutnya

Untuk counter, pendekatan paling aman biasanya bukan “baca kuat lalu tulis”, melainkan update atomik (mis. UpdateItem dengan ADD) sehingga increment tidak hilang.

Transaksi baca/tulis

Transaksi DynamoDB (TransactWriteItems, TransactGetItems) menyediakan semantik ACID hingga 25 item. Mereka berguna ketika Anda harus memperbarui beberapa item bersama—mis. menulis pesanan dan memesan inventaris—atau menegakkan invariant yang tidak boleh menerima keadaan perantara.

Idempotensi untuk retry aman

Retry adalah normal di sistem terdistribusi. Buat penulisan idempotent agar retry tidak menggandakan efek:

• Gunakan client request token (kunci idempotensi) yang disimpan bersama hasil
• Tegakkan keunikan dengan ConditionExpression (mis. “only create if attribute_not_exists”)
• Utamakan update atomik daripada loop baca-modifikasi-tulis

Kebenaran di DynamoDB sebagian besar soal memilih level konsistensi yang tepat dan merancang operasi sehingga retry tidak merusak data.

Partisi, Hot Keys, dan Lonjakan Trafik

DynamoDB menyimpan data tabel di beberapa partisi fisik. Setiap partisi memiliki throughput terbatas untuk baca dan tulis, serta batas berapa banyak data yang dapat disimpan. Kunci partisi Anda menentukan lokasi item; jika terlalu banyak permintaan menargetkan nilai kunci partisi yang sama, partisi tersebut menjadi bottleneck.

Mengapa partisi panas terjadi

Partisi panas biasanya disebabkan oleh pilihan kunci yang memusatkan trafik: kunci partisi “global” seperti USER#1, TENANT#default, atau STATUS#OPEN, atau pola berurutan waktu di mana semua orang menulis ke “sekarang” di bawah satu kunci partisi.

Gejala kunci panas dan trafik tidak merata

Anda biasanya akan melihat:

• Throttling (ProvisionedThroughputExceededException) untuk subset kunci tertentu
• Latensi tinggi dan spiking untuk beberapa pola akses sementara yang lain tetap cepat
• Metrik CloudWatch menunjukkan konsumsi kapasitas yang tidak merata dan lonjakan tiba-tiba

Teknik mitigasi

Rancang untuk distribusi terlebih dahulu, lalu kemudahan kueri:

• Desain kunci: pastikan kunci partisi memiliki kardinalitas tinggi (mis. TENANT#<id> daripada konstanta bersama).
• Sharding tulis: tambahkan sufiks/prefiks acak atau hash kecil seperti ORDER#<id>#<shard> untuk menyebarkan tulis ke N shard, lalu kueri lintas shard bila perlu.
• Time buckets: gunakan bucket per jam/hari (METRIC#2025-12-22T10) untuk mencegah semua penulisan mengarah ke item terbaru.

Menangani beban bursty

Untuk lonjakan tak terduga, on-demand dapat menyerap burst (dengan batas layanan). Pada mode provisioned, gunakan auto scaling dan terapkan exponential backoff dengan jitter pada retry klien untuk menghindari retry sinkron yang memperkuat lonjakan.

Pola Pemodelan Data untuk Sistem yang Skalabel

Pemodelan data di DynamoDB dimulai dari pola akses, bukan dari diagram ER. Anda merancang kunci sehingga kueri yang Anda butuhkan menjadi operasi Query yang cepat, sementara hal lain dihindari atau ditangani secara asinkron.

Desain satu-tabel (single-table) dan alasan tim menyukainya

“Desain satu-tabel” berarti menyimpan banyak tipe entitas (pengguna, pesanan, pesan) dalam satu tabel dan menggunakan konvensi kunci yang konsisten untuk mengambil data terkait dalam satu Query. Ini mengurangi round-trip lintas entitas dan menjaga latensi tetap terprediksi.

Pendekatan umum adalah kunci komposit:

• PK mengelompokkan partisi logis (mis. USER#123)
• SK mengurutkan item dalam grup itu (mis. PROFILE, ORDER#2025-12-01, MSG#000123)

Ini memungkinkan Anda mengambil “semua milik pengguna” atau “hanya pesanan pengguna” dengan memilih prefix pada sort key.

Relasi: adjacency list dan many-to-many

Untuk relasi mirip graf, adjacency list bekerja baik: simpan edge sebagai item.

• PK = USER#123, SK = FOLLOWS#USER#456

Untuk lookup terbalik atau many-to-many sejati, tambahkan item edge terbalik atau proyeksikan ke GSI, tergantung jalur baca.

Time-series: bucket + sort key + TTL

Untuk event dan metrik, hindari partisi tak terbatas dengan melakukan bucketing:

• PK = DEVICE#9#2025-12-22 (device + hari)
• SK = TS#1734825600 (timestamp)

Gunakan TTL untuk menghapus poin lama secara otomatis, dan simpan agregat (per jam/hari) sebagai item terpisah untuk dashboard yang cepat.

Jika ingin pembahasan lebih dalam tentang konvensi kunci, lihat /blog/partition-key-and-sort-key-design.

Streams dan Arsitektur Event-Driven

DynamoDB Streams adalah feed change-data-capture (CDC) bawaan DynamoDB. Saat diaktifkan pada tabel, setiap insert, update, atau delete menghasilkan record stream yang bisa dikonsumsi downstream—tanpa perlu polling tabel.

Dasar DynamoDB Streams

Record stream berisi kunci dan (opsional) gambaran lama/baru item, tergantung stream view type yang Anda pilih (keys only, new image, old image, both). Record dikelompokkan ke shard, yang Anda baca secara berurutan.

Membangun workflow event-driven

Setup umum adalah DynamoDB Streams → AWS Lambda, di mana setiap batch record memicu sebuah fungsi. Konsumen lain juga memungkinkan (konsumen custom, atau mem-pipe ke sistem analitik/logging).

Workflow tipikal meliputi:

• Materialized views: tulis model baca yang terdenormalisasi ketika tabel sumber berubah.
• Cache invalidation: kadaluarsa atau perbarui item di Redis/ElastiCache setelah penulisan.
• Audit logs: tambahkan event perubahan yang tidak dapat diubah ke tabel audit atau penyimpanan eksternal.

Ini menjaga tabel utama dioptimalkan untuk baca/tulis latensi rendah sementara pekerjaan turunan dipindahkan ke konsumen asinkron.

Ordering, retry, dan kebenaran

Streams menyediakan pemrosesan berurutan per shard (yang biasanya berkorelasi dengan kunci partisi), tetapi tidak ada ordering global antar semua kunci. Pengiriman bersifat at-least-once, jadi duplikat dapat terjadi.

Untuk menangani ini dengan aman:

• Buat handler idempotent (mis. upsert berdasarkan primary key, gunakan penulisan kondisional, atau simpan ID event yang sudah diproses).
• Antisipasi retry dan kegagalan batch parsial; gunakan DLQ/destinasi on-failure bila memungkinkan.
• Tempatkan efek samping (email, pembayaran) di balik deduplikasi atau pengaman transaksional.

Dengan desain yang mempertimbangkan jaminan ini, Streams dapat menjadikan DynamoDB tulang punggung yang andal untuk sistem event-driven.

Reliabilitas, Backup, dan Observabilitas

DynamoDB dirancang untuk ketersediaan tinggi dengan menyebarkan data ke beberapa Availability Zone dalam satu region. Untuk sebagian besar tim, keuntungan reliabilitas praktis datang dari strategi backup yang jelas, memahami opsi replikasi, dan memantau metrik yang tepat.

Backup: on-demand vs point-in-time recovery

On-demand backups adalah snapshot manual (atau otomatis) yang Anda ambil saat ingin titik pemulihan yang diketahui—sebelum migrasi, setelah rilis, atau sebelum backfill besar. Cocok untuk “bookmark” momen.

Point-in-time recovery (PITR) menangkap perubahan secara kontinu sehingga Anda bisa mengembalikan tabel ke kondisi pada detik tertentu dalam jendela retensi. PITR adalah jaring pengaman untuk penghapusan tidak sengaja, deploy rusak, atau penulisan yang keliru.

Replikasi dan opsi multi-region

Jika Anda butuh ketahanan multi-region atau pembacaan latensi rendah dekat pengguna, Global Tables mereplikasi data ke region terpilih. Mereka menyederhanakan rencana failover, tetapi memperkenalkan delay replikasi lintas-region dan pertimbangan resolusi konflik—jadi pertahankan pola penulisan dan kepemilikan item yang jelas.

Pengamatan yang wajib dimonitor

Minimal, beri alert pada:

• Latensi (p95/p99) untuk baca dan tulis
• Permintaan yang ditolak (throttled) dan error sistem
• Kapasitas yang dikonsumsi (dan headroom terhadap provisioned)

Sinyal-sinyal ini biasanya mengungkap masalah partisi panas, kapasitas tidak cukup, atau pola akses tak terduga.

Playbook insiden

Untuk throttling, cari pola akses yang menyebabkannya, lalu mitigasi dengan sementara beralih ke on-demand atau meningkatkan provisioned capacity, dan pertimbangkan sharding kunci panas.

Untuk outage parsial atau error meningkat, kurangi blast radius: nonaktifkan trafik non-kritis, retry dengan jittered backoff, dan gagal dengan anggun (mis. menyajikan bacaan dari cache) sampai tabel stabil.

Keamanan dan Kontrol Akses

Keamanan DynamoDB terutama tentang memperketat siapa yang dapat memanggil API mana, dari mana, dan pada kunci apa. Karena tabel dapat menampung banyak tipe entitas (dan kadang banyak tenant), kontrol akses harus dirancang bersamaan dengan model data.

IAM permissions: prinsip least privilege

Mulai dengan kebijakan IAM berbasis identitas yang membatasi aksi (mis. dynamodb:GetItem, Query, PutItem) ke set minimum dan menjangkau ARN tabel spesifik.

Untuk kontrol yang lebih halus, gunakan dynamodb:LeadingKeys untuk membatasi akses menurut nilai partition key—berguna ketika sebuah layanan atau tenant hanya boleh membaca/menulis item di keyspace-nya sendiri.

Enkripsi: apa yang perlu diverifikasi

DynamoDB mengenkripsi data at rest secara default menggunakan key milik AWS atau KMS yang dikelola pelanggan. Jika Anda memiliki kebutuhan kepatuhan, verifikasi:

• Tabel dikonfigurasi dengan KMS key yang dimaksud
• Role pemanggil punya izin KMS yang diperlukan (dan tidak lebih)

Untuk enkripsi in transit, pastikan klien menggunakan HTTPS (SDK AWS melakukannya secara default). Jika Anda terminasi TLS di proxy, pastikan hop antara proxy dan DynamoDB tetap terenkripsi.

Kontrol jaringan: kurangi jalur eksfiltrasi

Gunakan VPC Gateway Endpoint untuk DynamoDB sehingga trafik tetap di jaringan AWS dan Anda bisa menerapkan kebijakan endpoint untuk membatasi akses. Padukan ini dengan kontrol egress (NACL, security group, routing) untuk menghindari jalur “apa pun dapat mencapai internet publik”.

Desain multi-tenant dan pola isolasi

Untuk tabel bersama, sertakan identifier tenant dalam partition key (mis. TENANT#<id>), lalu tegakkan isolasi tenant dengan kondisi IAM pada dynamodb:LeadingKeys.

Jika butuh isolasi lebih kuat, pertimbangkan tabel terpisah per tenant atau per lingkungan, dan gunakan desain tabel bersama hanya jika kesederhanaan operasional dan efisiensi biaya mengalahkan kebutuhan blast-radius yang lebih kecil.

Optimasi Biaya untuk DynamoDB

DynamoDB sering “murah bila Anda presisi, mahal bila Anda kabur”. Biaya biasanya mengikuti pola akses, jadi pekerjaan optimasi terbaik dimulai dengan membuat pola-pola itu eksplisit.

Ketahui pemicu biaya

Tagihan Anda terutama dibentuk oleh:

• Baca dan tulis (RCU/WCU di mode provisioned, unit permintaan di on-demand)
• Penyimpanan (data tabel dan ukuran item)
• Secondary indexes (setiap GSI punya biaya tulis dan penyimpanan sendiri)
• Streams (pembacaan terhadap record stream dan konsumen downstream)

Kejutan umum: setiap tulis ke tabel juga merupakan tulis ke setiap GSI yang terpengaruh, jadi “satu indeks lagi” bisa menggandakan biaya tulis.

Rancang kunci untuk menghindari pemborosan

Desain kunci yang baik mengurangi kebutuhan operasi mahal. Jika Anda sering memakai Scan, Anda membayar untuk membaca data yang akan Anda buang.

Utamakan:

• Query berdasarkan kunci partisi (dan opsional kondisi kunci urut)
• Proyeksi sempit di GSI Anda (proyeksikan hanya atribut yang benar-benar diperlukan)

Jika pola akses jarang, pertimbangkan menyajikannya lewat tabel terpisah, job ETL, atau model baca ter-cache daripada GSI permanen.

Kendalikan penyimpanan dengan TTL dan lifecycle

Gunakan TTL untuk secara otomatis menghapus item yang bersifat singkat (session, token sementara, state workflow sementara). Ini memangkas penyimpanan dan menjaga indeks lebih kecil seiring waktu.

Untuk data yang banyak ditambahkan (events, logs), gabungkan TTL dengan desain kunci urut yang memungkinkan Anda mengkueri “hanya yang terbaru”, sehingga Anda tidak sering menyentuh riwayat dingin.

Right-size kapasitas dan hindari lonjakan tidak sengaja

Di mode provisioned, tetapkan baseline konservatif dan skalakan dengan auto scaling berdasarkan metrik nyata. Di mode on-demand, pantau pola tidak efisien (item besar, klien chatter) yang mendorong volume permintaan.

Anggap Scan sebagai pilihan terakhir—ketika Anda benar-benar perlu memproses seluruh tabel, jadwalkan itu pada jam off-peak atau jalankan sebagai batch terkontrol dengan pagination dan backoff.

Kapan Memilih DynamoDB (dan Kapan Tidak)

DynamoDB unggul ketika aplikasi Anda dapat diekspresikan sebagai sekumpulan pola akses yang jelas dan Anda membutuhkan latensi rendah yang konsisten pada skala besar. Jika Anda bisa mendeskripsikan baca/tulis utama di muka (berdasarkan partition key, sort key, dan beberapa indeks), ini seringkali salah satu cara paling sederhana untuk mengoperasikan penyimpanan yang highly available.

Cocok untuk kasus berikut

DynamoDB adalah pilihan kuat ketika Anda memiliki:

• Kueri yang dapat diprediksi (ambil profil pengguna, daftar pesanan pengguna berdasarkan waktu, muat session berdasarkan ID)
• Throughput tulis tinggi atau trafik spike yang tidak ingin Anda pantau terus-menerus
• Kebutuhan skala horizontal tanpa mengelola server
• Desain event-driven yang menggunakan Streams untuk memicu pekerjaan downstream

Kapan mempertimbangkan alternatif

Cari alternatif jika kebutuhan inti Anda meliputi:

• Join kompleks antar banyak entitas atau traversal relasi yang sering
• Kueri ad-hoc dan analitik yang berubah pekanan (group-by, filter eksploratori)
• Pencarian teks berat dan ranking relevansi tanpa indeks eksternal

Pendekatan hibrida yang bekerja baik

Banyak tim menjaga DynamoDB untuk bacaan/tulisan operasional “hot” lalu menambahkan:

• S3 + Athena untuk analitik dan pelaporan historis
• OpenSearch (atau serupa) untuk pencarian teks penuh dan faceting
• Lapisan cache ketika kunci tertentu sangat sering dibaca

Catatan prototipe: singkatkan jalur dari model ke aplikasi

Jika Anda memvalidasi pola akses dan konvensi single-table, kecepatan penting. Tim kadang membuat prototipe layanan dan UI di Koder.ai (platform vibe-coding yang membangun web, server, dan mobile apps dari chat) lalu mengiterasi desain kunci DynamoDB saat jalur kueri nyata muncul. Prototipe end-to-end cepat membantu mengungkap kueri mana yang seharusnya Query dibandingkan yang malah menjadi Scan mahal.

Daftar cek keputusan cepat

Validasi: (1) kueri teratas Anda diketahui dan berbasis kunci, (2) kebutuhan kebenaran cocok dengan model konsistensi, (3) ukuran item dan pertumbuhan dipahami, dan (4) model biaya (on-demand vs provisioned plus autoscaling) sesuai anggaran Anda.