Tentang Sesi Ini
Ringkasan & metadata
Sesi ini adalah cerita dari lapangan: bagaimana rasanya benar-benar menjalankan Amazon Aurora Serverless v2 — sebuah database relasional yang dapat menskalakan kapasitasnya sendiri secara otomatis — di lingkungan produksi sebuah perusahaan fintech, Doitpay. Judulnya menyindir istilah populer: "Beyond Auto Scaling". Auto scaling di tingkat server sudah biasa; yang lebih menarik adalah ketika database itu sendiri yang ikut mengembang dan menyusut mengikuti beban, dalam hitungan detik.
Aurora Serverless v2 mengukur kapasitas dalam satuan yang disebut ACU (Aurora Capacity Unit) — kira-kira sepasang "CPU + memori". Alih-alih Anda memilih ukuran instance tetap (misalnya "yang sedang" atau "yang besar") dan membayarnya 24 jam penuh, Aurora Serverless v2 menambah atau mengurangi ACU secara halus dan cepat sesuai kebutuhan nyata, dan Anda membayar sesuai pemakaian. Untuk beban yang naik-turun tajam, ini bisa jauh lebih hemat dan jauh lebih sedikit repot.
Kenapa penting untuk Anda? Kalau Anda mengelola startup atau produk dengan trafik tak menentu — ramai siang, sepi malam, melonjak saat promo — memilih ukuran database yang "pas" itu sulit. Terlalu kecil, layanan tersendat; terlalu besar, uang terbuang. Sesi ini menunjukkan jalan tengah otomatis, sekaligus jujur soal jebakannya.
Doitpay (dioperasikan PT Indoraya, berdiri 2023, berbasis di Batam) adalah payment gateway/aggregator asal Indonesia — bukan murni BNPL, melainkan infrastruktur pembayaran terpadu yang berlisensi di bawah Bank Indonesia. Lewat satu integrasi, merchant dapat menerima Virtual Account (BCA, Mandiri, BNI, BRI, BSI, Danamon), kartu debit/kredit, dompet digital (OVO, DANA, ShopeePay), QRIS, hingga pembayaran tunai di gerai ritel (Indomaret, Alfamart, Alfamidi); mereka juga menyediakan opsi paylater, remitansi, serta lending/investment. Fokus pasarnya: e-commerce & ritel, gaming & hiburan digital, serta travel dan transportasi. Pesaing yang kerap disebut: Xendit, PayU, dan Flutterwave. Beban transaksi khas pemroses pembayaran seperti ini memang fluktuatif (memuncak saat promo, gajian, atau jam sibuk) — pola yang cocok dengan database elastis seperti Aurora Serverless v2 yang dibahas sesi ini. Catatan penting: hingga penyusunan buku ini, kami tidak menemukan publikasi resmi yang memerinci arsitektur AWS/Aurora Doitpay; detail teknis (ACU, RDS Proxy, angka penskalaan) bersifat ilustratif.
Sumber: situs resmi doitpay.co; profil perusahaan Tracxn (doitpay.co); Instagram @doitpayco (PT Indoraya). Detail arsitektur spesifik sesi ilustratif kecuali disebutkan.
Apa Itu & Bagaimana Bekerjanya
Apa itu Aurora Serverless v2
Amazon Aurora adalah database relasional buatan AWS yang kompatibel dengan MySQL dan PostgreSQL. Versi Serverless v2 menambahkan satu kemampuan kunci: kapasitasnya elastis. Alih-alih menjalankan instance dengan ukuran tetap, Aurora Serverless v2 menyesuaikan kapasitas komputasinya secara otomatis dalam satuan ACU. Anda cukup menetapkan batas minimum dan maksimum ACU, dan database bergerak di antara keduanya mengikuti beban.
Dua sifat yang membuatnya berbeda dari pendahulunya (Serverless v1): penskalaannya halus (naik sedikit demi sedikit, bukan melompat menggandakan) dan cepat (dalam hitungan detik, tanpa memutus koneksi yang sedang berjalan). Karena Anda hanya membayar ACU yang benar-benar terpakai per detik, biaya mengikuti bentuk beban Anda — bukan puncak tertinggi sepanjang waktu.
Komponen & hal penting
Berikut istilah dan layanan pendukung yang muncul di sesi, beserta fungsi ringkasnya:
Poin praktisnya: Aurora Serverless v2 jarang berdiri sendiri. Untuk beban dengan banyak koneksi singkat (khas aplikasi web/serverless), RDS Proxy menjaga agar lonjakan koneksi tidak membebani database. CloudWatch dan Cost Monitoring menjadi mata Anda untuk memastikan penskalaan berperilaku wajar dan biaya tetap terkendali. Batas min/max ACU adalah tuas keselamatan Anda — terlalu rendah bisa bikin lambat saat ramai, terlalu tinggi bisa membiarkan biaya membengkak tak terduga.
Analogi yang Mudah Dicerna
Ibarat keran air pintar
Ibaratnya, Aurora Serverless v2 adalah keran air pintar di sebuah rumah. Keran biasa mengalirkan air dengan bukaan tetap, dan Anda menyewa pipa sebesar mungkin agar tidak kehabisan saat semua orang mandi bersamaan — padahal tengah malam pipa sebesar itu menganggur. Keran pintar ini mengecilkan alirannya sendiri saat rumah sepi, dan membesarkannya saat ramai. Yang terpenting: Anda membayar sesuai air yang benar-benar mengalir, bukan sewa pipa terbesar sepanjang waktu.
- Bukaan keran = jumlah ACU — mengecil saat sepi, membesar saat ramai.
- Debit minimum & maksimum = batas min/max ACU — pagar agar tak sepenuhnya mati saat sepi, dan tak jebol saat sangat ramai.
- Meteran air = Cost Monitoring & CloudWatch — Anda melihat berapa yang mengalir dan berapa biayanya.
- Tandon & katup pembagi = RDS Proxy — meratakan banyak permintaan air agar keran tidak "kaget" oleh lonjakan mendadak.
- Sedikit jeda saat keran dibuka dari nyaris tertutup = cold-ish start — kalau min ACU disetel terlalu rendah, tetes pertama saat tiba-tiba ramai bisa terasa telat.
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, aplikasi produksi yang memakai Aurora Serverless v2 terlihat seperti ini: aplikasi Anda tidak menyambung langsung ke database, melainkan lewat RDS Proxy yang mengelola kumpulan koneksi. Di belakangnya, klaster Aurora Serverless v2 menaik-turunkan ACU mengikuti beban, sementara CloudWatch dan Cost Monitoring memantau metrik penskalaan dan biaya.
Alur penskalaan saat lonjakan
Ketika trafik tiba-tiba melonjak (misalnya menit pertama sebuah flash sale), inilah yang terjadi di balik layar:
- Beban naik. Permintaan ke database meningkat; RDS Proxy menahan lonjakan koneksi agar tidak membanjiri klaster sekaligus.
- Aurora mendeteksi. Pemakaian CPU/memori naik mendekati kapasitas ACU saat ini.
- Naik halus. Aurora menambah ACU sedikit demi sedikit dalam hitungan detik, tanpa memutus koneksi berjalan — sampai batas max ACU.
- Beban mereda. Setelah puncak lewat, pemakaian turun.
- Turun otomatis. Aurora mengurangi ACU kembali menuju min ACU, sehingga biaya ikut turun.
- Terpantau. CloudWatch merekam kurva ACU & biaya untuk ditinjau dan disetel ulang bila perlu.
Dari Konsep ke Bisnis Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan yang khas — termasuk pengalaman Doitpay sendiri.
Beban fluktuatif ala Doitpay
Sebuah platform pembayaran seperti Doitpay punya pola trafik yang tajam: tenang di dini hari, memuncak saat jam gajian, tanggal tua, atau kampanye promo mitra. Dengan Aurora Serverless v2, kapasitas database mengikuti kurva ini tanpa harus menyetel ulang ukuran instance manual. RDS Proxy meredam lonjakan koneksi dari banyak layanan mikro, sementara batas min/max ACU dijaga agar transaksi tetap lancar di puncak namun biaya tak liar. Pelajaran jujur mereka: pantau Cost Monitoring sejak hari pertama, karena penskalaan yang "terlalu bebas" bisa mengejutkan di tagihan.
Hemat biaya database di tahap awal
Startup tahap awal biasanya belum tahu seberapa besar bebannya, dan sayang membayar instance besar 24 jam untuk trafik yang masih kecil. Aurora Serverless v2 membiarkan mereka menyetel min ACU rendah agar murah saat sepi, namun tetap siap membesar otomatis bila produk tiba-tiba viral. Tak perlu menebak ukuran instance di awal — kapasitas mengikuti pertumbuhan nyata.
Trafik tak menentu antar pelanggan
Produk SaaS B2B sering punya beban yang tak terprediksi: satu pelanggan besar menjalankan laporan bulanan berat, lalu sunyi berhari-hari. Dengan penskalaan halus per detik, database mengembang saat laporan dijalankan dan menyusut sesudahnya. Observability membantu tim melihat pelanggan mana yang mendorong lonjakan, dan RDS Proxy menjaga koneksi tetap sehat meski jumlah tenant bertambah.
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
- Database pun bisa elastis. Aurora Serverless v2 menaik-turunkan kapasitas (ACU) secara halus & cepat, dan Anda bayar sesuai pemakaian.
- Cocok untuk beban fluktuatif. Untuk trafik yang naik-turun tajam, ini lebih hemat dan lebih sedikit repot daripada memilih ukuran instance tetap.
- Setel pagarnya. Batas min/max ACU menentukan keseimbangan antara kecepatan saat ramai dan biaya saat sepi — pilih dengan sadar.
- Lengkapi dengan pendamping. RDS Proxy untuk koneksi, CloudWatch & Cost Monitoring untuk memantau — pengalaman Doitpay menegaskan: awasi biaya sejak hari pertama.