Pada aplikasi POS, inventory, payroll, marketplace, atau koperasi, tantangan backend tidak berhenti ketika data berhasil disimpan. Sistem harus memastikan stok, saldo, pembayaran, dan laporan tetap konsisten meskipun request dikirim ulang, layanan pihak ketiga terlambat, atau proses berhenti di tengah jalan.
Mulai dari aturan bisnis, bukan tabel
Sebelum menentukan skema database, petakan dahulu kejadian bisnis: penjualan dibuat, pembayaran diterima, stok berkurang, pesanan dibatalkan, atau dana dikembalikan. Setiap kejadian perlu memiliki prasyarat, perubahan data, dan hasil yang jelas.
Gunakan transaksi database secara tepat
Perubahan yang harus berhasil bersama sebaiknya berada dalam satu transaksi database. Contohnya, detail penjualan, mutasi stok, dan total transaksi tidak boleh menyisakan kondisi setengah jadi. Transaksi perlu singkat; pemanggilan API eksternal sebaiknya tidak menahan lock database.
Idempotency untuk request yang dapat diulang
Payment gateway dan aplikasi klien dapat mengirim request atau callback lebih dari satu kali. Gunakan referensi unik dan pemeriksaan status agar request yang sama tidak membuat pembayaran, saldo, atau stok tercatat dua kali.
Simpan mutasi, jangan hanya saldo akhir
Saldo atau stok akhir berguna untuk akses cepat, tetapi riwayat mutasi diperlukan untuk penelusuran. Catat sumber transaksi, nilai sebelum dan sesudah perubahan, waktu, serta pelaku atau layanan yang memicu proses.
Reconciliation sebagai proses rutin
Status internal dan status penyedia pembayaran dapat berbeda karena timeout atau gangguan jaringan. Proses rekonsiliasi membandingkan kedua sisi, menandai perbedaan, dan menyediakan langkah koreksi yang dapat ditelusuri.
Authorization dan isolasi tenant
Pada sistem multi-tenant, filter tenant harus menjadi bagian dari pola akses data, bukan sekadar parameter dari frontend. Setiap query, aksi administratif, dan laporan perlu mematuhi batas akses yang sama.
Observability untuk production support
Log terstruktur sebaiknya membawa correlation ID, nomor transaksi, status, dan konteks kegagalan tanpa menyimpan data sensitif. Dengan informasi tersebut, engineer dapat mengikuti satu transaksi melintasi beberapa proses dan menemukan titik kegagalan.
Kesimpulan
Backend aplikasi bisnis yang matang dibangun dengan kombinasi aturan bisnis yang eksplisit, transaksi database, idempotency, riwayat mutasi, rekonsiliasi, authorization, serta logging yang dapat ditindaklanjuti. Praktik ini membuat sistem lebih mudah dirawat dan lebih aman ketika volume serta kompleksitas operasional bertambah.
