Tentang Sesi Ini
Ringkasan & metadata
Sesi tingkat ahli ini membedah satu prinsip yang menjadi tulang punggung aplikasi modern berskala web: purpose-built databases — memilih database dan layanan analitik yang dirancang khusus untuk tiap beban kerja, alih-alih memaksakan satu database relasional untuk semua kebutuhan. Selama bertahun-tahun, pola default adalah "satu database untuk seluruh aplikasi". Pola itu nyaman di awal, tetapi mulai retak ketika trafik membesar, bentuk data beragam, dan pola akses berbeda-beda antar fitur.
Realitanya, satu aplikasi web besar bukanlah satu beban kerja tunggal. Katalog produk butuh pencarian teks yang relevan, keranjang belanja butuh latensi rendah pada skala masif, transaksi pembayaran butuh konsistensi kuat & jaminan ACID, dasbor bisnis butuh agregasi analitik atas miliaran baris, dan fitur "teman Anda juga membeli" butuh penelusuran relasi (graph). Memaksakan semua itu ke satu mesin berarti berkompromi di banyak tempat sekaligus. AWS menawarkan katalog layanan data yang masing-masing dioptimalkan untuk satu jenis pekerjaan.
Kenapa penting untuk Anda? Jika aplikasi Anda mulai melambat, mahal, atau sulit diskalakan karena satu database dipaksa mengerjakan segalanya, sesi ini memberi peta jalan untuk memecah beban kerja ke layanan yang paling pas — dan pola arsitektur data polyglot untuk menyatukannya kembali.
Satu Alat untuk Satu Tugas
Prinsip purpose-built
Ide pokoknya sederhana namun mengubah cara berpikir: tidak ada satu database yang unggul di segala dimensi. Sebuah mesin yang hebat untuk transaksi keuangan (konsisten, terstruktur, ACID) belum tentu efisien untuk menyimpan sesi pengguna bervolume jutaan per detik, dan hampir pasti buruk untuk pencarian teks bebas atau agregasi analitik. Setiap kategori database membuat trade-off yang berbeda antara konsistensi, latensi, throughput, fleksibilitas skema, dan biaya.
Karena itu, arsitektur purpose-built menerima kenyataan bahwa data akan tersebar di beberapa penyimpanan — sebuah pendekatan yang disebut polyglot persistence. Alih-alih menganggapnya kerumitan yang harus dihindari, kita memperlakukannya sebagai keputusan desain sadar: tiap beban kerja dipetakan ke layanan yang paling cocok, lalu disatukan lewat pola integrasi (event, stream, atau replikasi) yang terkontrol.
Tiga pertanyaan yang dipakai sesi ini untuk memilih layanan: (1) Bentuk data — relasional, key-value, dokumen, teks, deret waktu, atau graph? (2) Pola akses — banyak baca titik-tunggal, agregasi range luas, pencarian relevansi, atau penelusuran relasi? (3) Kebutuhan non-fungsional — konsistensi, latensi target, skala, dan anggaran biaya.
Peta layanan & kapan dipakai
Berikut peta ringkas layanan data AWS yang dibahas, beserta beban kerja yang paling cocok untuk masing-masing:
| Beban kerja | Bentuk / pola | Layanan yang cocok |
|---|---|---|
| Transaksi & pembayaran | Relasional, ACID, join | Amazon Aurora / RDS |
| Keranjang, sesi, profil | Key-value skala masif | Amazon DynamoDB |
| Halaman panas, hasil berulang | Cache in-memory | Amazon ElastiCache |
| Pencarian katalog, log | Full-text, relevansi | Amazon OpenSearch |
| Dasbor & laporan bisnis | Agregasi kolumnar | Amazon Redshift |
| Rekomendasi, jejaring | Graph, traversal relasi | Amazon Neptune |
| Metrik IoT / telemetri | Deret waktu (time-series) | Amazon Timestream |
Tujuh kategori ini bukan daftar yang harus dipakai sekaligus. Justru sebaliknya: mulai dari satu atau dua yang paling menyakitkan, lalu tambah layanan lain saat beban kerja baru muncul. Kuncinya adalah memetakan tiap fitur ke alat yang tepat, bukan menumpuknya di satu tempat.
Analogi yang Mudah Dicerna
Ibarat kotak perkakas
Ibaratnya, membangun aplikasi web besar itu seperti mengerjakan renovasi rumah. Seorang tukang berpengalaman tidak memaksakan satu palu untuk semua pekerjaan. Untuk memaku ia pakai palu, untuk sekrup ia pakai obeng, untuk memotong kayu ia pakai gergaji, untuk mengukur ia pakai meteran. Memaksakan palu untuk memasang sekrup mungkin "bisa", tetapi lambat, merusak, dan hasilnya buruk. Purpose-built databases adalah kotak perkakas untuk data: tiap tugas punya alat khusus yang paling pas.
- Aurora / RDS = kunci pas presisi — untuk sambungan yang harus kencang & akurat (transaksi keuangan).
- DynamoDB = paku tembak cepat — melepas ribuan paku per menit tanpa lelah (keranjang, sesi, skala masif).
- ElastiCache = alat yang selalu di sabuk pinggang — diraih dalam sekejap, tanpa bolak-balik ke gudang (cache).
- OpenSearch = detektor logam — menemukan barang tepat di tumpukan besar (pencarian teks & log).
- Redshift = meja kerja besar — tempat menyusun & menganalisis banyak potongan sekaligus (analitik).
- Neptune = benang penanda hubungan — menelusuri "siapa terhubung ke siapa" (graph & rekomendasi).
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, aplikasi web berskala di atas arsitektur data purpose-built terlihat seperti ini: sebuah lapisan aplikasi / API menerima permintaan pengguna, lalu mengarahkan tiap operasi ke penyimpanan yang tepat. Transaksi ke Aurora, keranjang & sesi ke DynamoDB, hasil panas dilayani lewat ElastiCache, pencarian ke OpenSearch, sementara perubahan data mengalir (lewat stream/event) ke Redshift untuk analitik dan ke Neptune untuk relasi.
Alur data polyglot satu transaksi
Ketika seorang pengguna menekan "Bayar" di sebuah marketplace, inilah yang terjadi di balik layar melintasi beberapa penyimpanan:
- Tulis transaksi. Pesanan & pembayaran ditulis ke Aurora secara ACID — tidak boleh ada uang hilang atau ganda.
- Perbarui state cepat. Status keranjang & sesi diperbarui di DynamoDB dengan latensi milidetik.
- Layani ulang dari cache. Halaman konfirmasi memakai ElastiCache agar respons instan tanpa membebani database utama.
- Alirkan perubahan. Event "pesanan dibuat" mengalir lewat stream ke OpenSearch (indeks pencarian) & Redshift (analitik).
- Perbarui relasi. Neptune mencatat "pengguna X membeli produk Y" untuk memperkaya rekomendasi.
- Konsistensi terkelola. Sumber kebenaran tetap di Aurora; salinan turunan bersifat eventually consistent secara sadar.
Dari Konsep ke Bisnis Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan yang khas di Indonesia.
Katalog + keranjang + pencarian dengan database berbeda
Sebuah marketplace besar memisahkan beban kerjanya: katalog produk & transaksi memakai Aurora agar konsisten; keranjang belanja & sesi jutaan pengguna ditaruh di DynamoDB yang tetap kencang saat flash sale; pencarian produk ("sepatu lari pria hitam") dilayani OpenSearch agar relevan dan cepat; dan halaman panas dipercepat ElastiCache. Hasilnya: tiap fitur diskalakan sendiri-sendiri tanpa saling menyeret, dan biaya menjadi proporsional dengan beban masing-masing.
Telemetri kendaraan & deret waktu
Sebuah platform ride-hailing / logistik menerima jutaan sinyal lokasi & sensor per menit. Data telemetri deret waktu masuk ke Amazon Timestream yang dioptimalkan untuk pola tulis-berat & kueri rentang waktu; DynamoDB menyimpan state pesanan aktif; dan agregasi harian mengalir ke Redshift untuk memantau performa armada. Memaksakan ini ke satu database relasional akan cepat kolaps di volume tulis setinggi itu.
"Teman Anda juga membeli" & dasbor bisnis
Sebuah layanan konten/keuangan memakai Neptune untuk memodelkan graf hubungan pengguna–produk–minat, sehingga rekomendasi bisa menelusuri relasi berlapis dalam milidetik. Sementara itu, tim bisnis menjalankan kueri agregasi berat (pendapatan per wilayah, kohort retensi) di Redshift tanpa mengganggu database transaksional. Data pindah antar keduanya lewat pipeline event yang terkontrol, menjaga sistem produksi tetap responsif.
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
- Tidak ada database serba bisa. Tiap kategori punya trade-off; pilih yang cocok dengan bentuk data & pola akses.
- Petakan beban kerja ke alat yang tepat. Transaksi → Aurora, key-value skala → DynamoDB, cache → ElastiCache, cari → OpenSearch, analitik → Redshift, graph → Neptune, deret waktu → Timestream.
- Polyglot itu keputusan sadar, bukan kekacauan. Satukan lewat stream/event dengan konsistensi yang dikelola.
- Mulai bertahap. Pisahkan beban kerja paling menyakitkan lebih dulu, lalu perluas seiring pertumbuhan.