Tentang Sesi Ini
Ringkasan & metadata
Sesi ini membedah Amazon DocumentDB — database dokumen terkelola sepenuhnya yang kompatibel dengan MongoDB — beserta fitur-fitur terbarunya yang dirancang untuk satu tujuan: performa setinggi mungkin dengan beban operasional serendah mungkin. Level 400 berarti kita tidak berhenti pada "apa itu"; kita masuk ke arsitektur, pola akses, tuning, dan trade-off yang menentukan sukses-tidaknya sebuah sistem di produksi.
Yang membuat sesi ini istimewa: pembicara dari SiCepat Ekspres Indonesia berbagi pengalaman nyata mengoperasikan DocumentDB untuk beban kerja logistik — data pengiriman dan pelacakan (tracking) berjutaan resi per hari, yang harus ditulis cepat saat paket bergerak dan dibaca instan saat pelanggan menekan tombol "Lacak". Ini adalah kelas berat di mana volume, latensi, dan biaya bertabrakan setiap detik.
Kenapa penting untuk Anda? Jika tim Anda mengelola data semi-terstruktur bervolume tinggi (katalog, profil pengguna, event, tracking) dan lelah mengurus sharding, patching, dan backup manual, sesi ini menunjukkan cara memindahkan beban operasional itu ke layanan terkelola tanpa mengorbankan performa.
SiCepat Ekspres adalah perusahaan logistik/kurir asal Indonesia yang berdiri pada 2014 dan tumbuh pesat bersama ledakan e-commerce. Skalanya masif: volume pengiriman menembus sekitar 800 ribu paket per hari pada Oktober 2020, sempat disebut mencapai 1 juta paket per hari, dan sepanjang 2021 tercatat lebih dari 2,8 juta paket per hari (pertumbuhan tahunan hingga 93%). Volume sebesar ini — dengan ledakan tulis saat kurir memindai paket dan ledakan baca saat pelanggan menekan "Lacak" — persis jenis beban kerja bervolume tinggi yang menjadi tema sesi MAM401. SiCepat tercatat sebagai pelanggan korporat AWS sejak 2020; use case yang dipublikasikan AWS berpusat pada analitik data: AWS Glue untuk pipeline ETL, Amazon S3 sebagai data lake terpusat, serta Amazon Redshift dan Amazon Athena untuk memproses dan mengueri data operasional.
Sumber: studi kasus AWS "SiCepat Ekspres" (aws.amazon.com) dan pemberitaan Kontan serta Kompas soal volume pengiriman harian. Catatan: penggunaan Amazon DocumentDB secara spesifik tidak dipublikasikan; case study AWS yang tersedia menyoroti stack analitik (Glue/S3/Redshift/Athena), bukan DocumentDB. Detail arsitektur spesifik sesi bersifat ilustratif kecuali disebutkan.
Apa Itu & Bagaimana Bekerjanya
Apa itu DocumentDB
Amazon DocumentDB adalah database dokumen: alih-alih menyimpan data dalam tabel baris-kolom yang kaku (model relasional), ia menyimpan tiap entitas sebagai dokumen JSON yang fleksibel. Satu dokumen "kiriman" bisa memuat pengirim, penerima, daftar riwayat scan, dan status — semuanya dalam satu objek yang bisa dibaca sekali ambil, tanpa perlu menggabungkan (join) enam tabel.
Perbedaan mendasar dengan relasional:
| Aspek | Relasional (SQL) | Dokumen (DocumentDB) |
|---|---|---|
| Bentuk data | Tabel, baris, kolom tetap | Dokumen JSON, skema fleksibel |
| Perubahan skema | Migrasi kolom, sering mahal | Tambah field kapan saja |
| Membaca satu entitas | JOIN beberapa tabel | Satu dokumen, satu kali ambil |
| Cocok untuk | Transaksi ketat, relasi kompleks | Katalog, profil, event, tracking |
Karena kompatibel dengan API MongoDB, tim yang sudah memakai driver, tool, dan query MongoDB dapat berpindah dengan perubahan kode minimal — tetapi kini di atas infrastruktur terkelola AWS yang menangani patching, backup, dan ketersediaan tinggi secara otomatis.
Fitur & kemampuan (yang dibahas)
Inti daya tarik DocumentDB terletak pada pemisahan compute (mesin yang memproses query) dari storage (lapisan penyimpanan yang otomatis mengembang). Dari fondasi itu, lahir kemampuan-kemampuan berikut:
Ketujuh kemampuan ini bisa dipadukan. Sebuah beban kerja tracking, misalnya, memakai replika baca untuk menyerap ledakan permintaan "Lacak", auto scaling storage agar tak pernah kehabisan ruang saat volume kiriman naik menjelang harbolnas, I/O-optimized agar biaya tetap terprediksi, dan global cluster untuk kesiapan pemulihan bencana.
Analogi yang Mudah Dicerna
Kendaraan yang servis & isi bahan bakar sendiri
Ibaratnya, mengelola database sendiri seperti punya armada kurir yang harus Anda servis manual: ganti oli, isi bensin, cek ban, ganti suku cadang — semua menyita waktu yang seharusnya dipakai mengantar paket. Amazon DocumentDB adalah kendaraan yang mengurus dirinya sendiri. Ia mengisi bahan bakar otomatis (storage tumbuh sendiri), servis berkala tanpa Anda hentikan (patching & backup otomatis), dan menambah kendaraan cadangan sendiri saat antrean panjang (replika baca). Sopir tinggal fokus mengantar paket — tim Anda tinggal fokus pada aplikasi dan pelanggan.
- Isi bahan bakar otomatis = auto scaling storage — tangki tak pernah kosong, Anda hanya bayar bensin yang terpakai.
- Servis tanpa berhenti = patching & backup berkelanjutan — perawatan berjalan tanpa mematikan mesin.
- Kendaraan cadangan = replika baca — saat banyak penumpang (permintaan baca), armada bertambah sendiri.
- Cabang di kota lain = global cluster — jika satu kota terkena bencana, operasi lanjut dari kota lain.
- Dasbor & kotak hitam = observability — tiap perjalanan tercatat, mudah dievaluasi.
High-Level Architecture & Alur
High-Level Architecture (HLA)
Kunci arsitektur DocumentDB adalah pemisahan compute dan storage. Instance (primary untuk tulis, hingga 15 replika untuk baca) berbagi satu lapisan storage terdistribusi yang menyalin data enam kali di tiga Availability Zone. Karena storage terpisah, menambah replika baca tidak menyalin ulang data — replika langsung membaca dari lapisan yang sama, sehingga skala baca menjadi cepat dan murah, dan failover berlangsung dalam hitungan detik.
Alur baca & tulis satu resi
Ketika kurir memindai (scan) sebuah paket dan, tak lama kemudian, pelanggan menekan "Lacak", inilah yang terjadi:
- Tulis ke primary. Event scan (misal "Paket tiba di hub Cakung") ditulis sebagai pembaruan dokumen ke instance primary.
- Persist ke storage. Perubahan langsung tersimpan tahan-lama di lapisan storage terdistribusi (enam salinan), bukan menunggu disalin ke tiap replika.
- Replika ikut terbaru. Replika baca membaca dari storage yang sama, jadi cepat menampilkan status terbaru.
- Baca dari replika. Permintaan "Lacak" pelanggan diarahkan ke replika baca (reader endpoint), menjaga primary tetap ringan untuk menulis.
- Skala saat lonjakan. Saat trafik "Lacak" meledak, tambah replika — tanpa menyalin ulang data.
- Pantau. Observability merekam latensi & throughput tiap langkah untuk tuning.
Dari Konsep ke Bisnis Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan model dokumen yang khas di Indonesia.
Pelacakan & status kiriman real-time
Tiap resi adalah satu dokumen yang menampung seluruh riwayat scan: dijemput, masuk hub, transit, keluar untuk antar, diterima. Ledakan tulis terjadi saat ribuan kurir memindai serentak; ledakan baca terjadi saat pelanggan menekan "Lacak". Replika baca menyerap trafik "Lacak" tanpa membebani penulisan, auto scaling storage mengikuti lonjakan volume harbolnas, dan I/O-optimized menjaga biaya tetap terprediksi. Model dokumen menghindari join berlapis: satu kali ambil, status lengkap tampil.
Katalog produk yang beragam
Katalog marketplace penuh produk dengan atribut berbeda-beda: ponsel punya RAM & kamera, baju punya ukuran & bahan, buku punya penulis & ISBN. Skema fleksibel dokumen membiarkan tiap produk membawa field-nya sendiri tanpa kolom kosong yang boros. Indeks pada atribut yang sering difilter membuat pencarian & faceting cepat, dan replika baca menopang lonjakan penelusuran saat kampanye promo.
Profil & preferensi pengguna
Aplikasi konten menyimpan profil pengguna: preferensi, riwayat tontonan, daftar simpan, pengaturan. Semua cocok sebagai satu dokumen per pengguna yang diambil sekali saat login. Saat basis pengguna tumbuh, storage mengembang otomatis dan replika baca menjaga waktu muat tetap ringan — tanpa tim harus begadang mengurus sharding manual.
Ringkasan Visual (Geser)
Ringkasan visual
Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.
Poin yang Bisa Dibawa Pulang
Poin yang bisa dibawa pulang
- Pilih model dokumen saat data semi-terstruktur & dibaca sebagai satu entitas — katalog, profil, tracking. Bukan pengganti relasional untuk transaksi berelasi ketat.
- Pemisahan compute–storage adalah inti performanya. Menambah replika baca tidak menyalin ulang data — skala baca cepat & murah, failover cepat.
- Biarkan layanan mengurus operasional. Auto scaling storage, patching, backup/PITR, dan global cluster menekan beban tim.
- Level ahli = tuning berbasis pola akses. Pisahkan endpoint baca/tulis, rancang indeks sesuai query, pilih I/O-optimized untuk beban I/O tinggi, dan pantau dengan Performance Insights.