RDS & Aurora untuk aplikasi Go

Database terkelola menghilangkan pekerjaan operasional, tapi tidak menghilangkan keputusan: berapa koneksi, ke endpoint mana, dan apa yang terjadi pada pool-mu saat failover berlangsung.

Endpoint dan perannya

toko.cluster-abc123.ap-southeast-1.rds.amazonaws.com          ← WRITER
toko.cluster-ro-abc123.ap-southeast-1.rds.amazonaws.com       ← READER (menyebar)
toko-instance-1.abc123.ap-southeast-1.rds.amazonaws.com       ← instans tertentu
                                                                (jangan dipakai aplikasi)

type DB struct {
	Tulis *pgxpool.Pool
	Baca  *pgxpool.Pool
}

func Buka(ctx context.Context, cfg config.Config) (*DB, error) {
	tulis, err := bukaPool(ctx, cfg.DSNWriter, 20)
	if err != nil {
		return nil, err
	}

	// Reader boleh punya pool lebih besar: kueri baca biasanya lebih pendek,
	// dan replica-nya bisa lebih dari satu.
	baca, err := bukaPool(ctx, cfg.DSNReader, 30)
	if err != nil {
		tulis.Close()
		return nil, err
	}
	return &DB{Tulis: tulis, Baca: baca}, nil
}

// Repository memutuskan pool mana — domain tidak perlu tahu (Fase 5).
func (r *Repo) Ambil(ctx context.Context, id int64) (Produk, error) {
	return ambil(ctx, r.db.Baca, id)      // boleh sedikit basi
}

func (r *Repo) Simpan(ctx context.Context, p Produk) error {
	return simpan(ctx, r.db.Tulis, p)
}

// Baca-setelah-tulis WAJIB ke writer: replica bisa tertinggal.
func (r *Repo) AmbilSetelahTulis(ctx context.Context, id int64) (Produk, error) {
	return ambil(ctx, r.db.Tulis, id)
}

Failover

t=0    Instans writer bermasalah
t=5    Aurora mempromosikan reader jadi writer baru
t=6    DNS cluster endpoint menunjuk instans baru (TTL ~5 detik)
t=6    ❌ Pool aplikasi MASIH memegang 20 koneksi ke instans lama
       → semua tulisan gagal "cannot execute INSERT in a read-only transaction"
       → dan TIDAK pulih sendiri, karena koneksinya tidak pernah kedaluwarsa

✅ Dengan ConnMaxLifetime = 5 menit:
   koneksi dibuang bertahap, DNS di-resolve ulang, pool pindah sendiri

cfg.MaxConnLifetime = 5 * time.Minute       // lebih pendek dari biasanya
cfg.MaxConnIdleTime = 1 * time.Minute
cfg.HealthCheckPeriod = 30 * time.Second

Memilih konfigurasi

Batas koneksi

max_connections di RDS ditentukan ukuran instans:

  db.t4g.medium (4 GB)    ≈ 340
  db.r6g.large  (16 GB)   ≈ 1.600
  db.r6g.xlarge (32 GB)   ≈ 3.000

Hitung untuk jumlah task MAKSIMUM (Fase 4):

  (MaxOpenConns × task web) + (worker) + (cron) + cadangan < max_connections

  20 × 20 web  = 400
  10 ×  4 work =  40
  10 ×  1 cron =  10
  cadangan     =  25   (migrasi, psql darurat, monitoring)
  ──────────────────
  total        = 475   → butuh instans yang lebih besar dari t4g.medium

Kredensial dan rotasi

Opsi A: Secrets Manager dengan rotasi terkelola
  ✅ sederhana, kredensial berputar otomatis
  ⚠️ rotasi harus memicu deployment baru, atau aplikasi harus memuat ulang

Opsi B: Autentikasi IAM ke database
  ✅ tanpa sandi sama sekali; token berumur 15 menit
  ⚠️ ada batas laju pembuatan token; perlu penanganan di kode

// TLS ke RDS bukan opsional (Fase 6)
dsn := "postgres://pengguna:sandi@host:5432/toko?sslmode=verify-full&pool_max_conns=20"

Yang harus dipantau

Cadangan dan pemulihan

1. Backup otomatis minimal 7 hari; 30 hari untuk data yang menyangkut uang.
2. Point-in-time recovery aktif — menyelamatkan dari DELETE tanpa WHERE.
3. Perlindungan penghapusan aktif di produksi.
4. Uji pemulihannya setahun sekali. Backup yang belum pernah dipulihkan bukan backup.
5. Snapshot manual sebelum migrasi besar — dan sebelum setiap perubahan skema yang tidak bisa dibatalkan.