Mengonsolidasikan 3 Lapis Database Menjadi 2, Tanpa Downtime

Selama bertahun-tahun, Sitetisfy CMS berjalan di atas tiga lapis database: satu database global, satu database SSO, dan N shard per grup tenant. Model ini berhasil menampung pertumbuhan awal, tapi juga menimbulkan beban operasional yang makin terasa: setiap fitur lintas-tenant butuh query lintas-connection, dan menambah shard baru berarti koordinasi manual yang rawan salah.

Kenapa 2 database, bukan 1

Kami tetap memisahkan data konten (new_sitetisfy_cms) dari data identitas/billing (new_sitetisfy_sso). Pemisahan ini bukan soal skala, tapi soal blast radius: insiden pada layanan konten tidak boleh pernah menyentuh data kredensial dan tagihan.

Isolasi antar-tenant yang sebelumnya dilakukan lewat connection terpisah per shard, sekarang murni lewat kolom company_id yang sudah ada di setiap tabel konten.

Strategi migrasi: dual-write dulu, baru cutover

Alih-alih migrasi big-bang, kami menjalankan periode dual-write: setiap write ke database lama juga direplikasi ke database baru lewat job queue, sambil traffic baca tetap dilayani database lama. Begitu checksum antara dua sisi konsisten untuk seluruh tenant, barulah traffic baca dialihkan, dan database lama dibekukan sebagai fallback selama satu minggu sebelum benar-benar dimatikan.

Pendekatan ini membuat seluruh proses migrasi berjalan tanpa jendela downtime yang terlihat pengguna — hanya serangkaian toggle konfigurasi yang bisa di-rollback kapan saja selama periode transisi.