Kategori: Programming | Perkiraan waktu baca: 8 menit
Salah satu modul yang paling sering dipakai di ARES — platform SaaS manajemen fasilitas yang saya kembangkan — adalah fitur booking ruangan. Kedengarannya simpel ("kan cuma pilih ruangan, pilih jam"), tapi begitu masuk ke detail implementasi, ada banyak hal yang ternyata perlu dipikirkan matang-matang.
Di artikel ini saya mau share proses berpikir dan keputusan teknis di balik fitur ini — bukan tutorial step-by-step, tapi lebih ke studi kasus dari sisi problem solving.
Masalah yang Coba Diselesaikan
Sebelum ARES, proses booking ruangan meeting di banyak kantor (termasuk yang pernah saya temui langsung) masih manual: chat WhatsApp ke admin, admin cek jadwal di Excel, konfirmasi manual, dan sering banget kejadian double booking karena dua orang chat admin di waktu yang hampir bersamaan.
Requirement utamanya jadi jelas:
- User bisa lihat ketersediaan ruangan real-time
- Sistem harus mencegah double booking secara otomatis, bukan mengandalkan manusia yang teliti
- Ada approval flow untuk ruangan tertentu yang butuh persetujuan (misal ruang meeting VIP)
- Harus bisa diakses multi-tenant — beda perusahaan pakai instance ARES yang sama tapi datanya terpisah total
Keputusan Desain #1: Mencegah Double Booking di Level Database
Ini bagian paling krusial. Godaan paling umum adalah cuma cek ketersediaan di sisi frontend sebelum submit — tapi itu punya race condition yang jelas: dua user bisa saja submit booking yang overlap dalam hitungan milidetik sebelum validasi sempat jalan.
Solusi yang saya pakai: manfaatkan constraint di level database (Supabase/PostgreSQL), bukan cuma validasi di aplikasi. Menggunakan extension btree_gist, saya bisa bikin exclusion constraint yang secara fisik mencegah dua row dengan rentang waktu overlap untuk ruangan yang sama:
create extension if not exists btree_gist;
alter table bookings
add constraint no_overlapping_bookings
exclude using gist (
room_id with =,
tstzrange(start_time, end_time) with &&
);
Dengan constraint ini, kalaupun ada dua request booking yang nyaris bersamaan, database sendiri yang akan menolak salah satunya — nggak peduli seberapa cepat request itu datang. Ini jauh lebih reliable dibanding validasi manual di kode aplikasi.
Keputusan Desain #2: Approval Flow yang Fleksibel
Nggak semua ruangan butuh approval — ruang meeting kecil biasanya bisa langsung booking, tapi ruang khusus (misal ruang direksi) butuh persetujuan dulu. Saya desain ini sebagai properti per-ruangan, bukan hardcode:
alter table rooms add column requires_approval boolean default false;
Kalau requires_approval = true, booking masuk dengan status pending dan trigger notifikasi ke approver. Kalau false, langsung confirmed. Fleksibilitas ini penting karena tiap perusahaan yang pakai ARES punya kebijakan berbeda-beda soal ruangan mana yang perlu approval.
Keputusan Desain #3: Isolasi Data Multi-Tenant
Karena ARES dipakai banyak perusahaan berbeda dalam satu sistem yang sama, data satu tenant nggak boleh bisa "bocor" ke tenant lain — bahkan kalau ada bug di kode aplikasi sekalipun. Solusinya, seperti yang saya bahas juga di artikel Next.js + Supabase sebelumnya, saya andalkan Row Level Security:
create policy "Tenant isolation for bookings"
on bookings for select
using (tenant_id = (select tenant_id from users where id = auth.uid()));
Jadi meskipun ada celah di logic frontend, database sendiri yang menjaga supaya query cuma bisa mengembalikan data milik tenant yang sedang login. Ini lapisan keamanan yang saya anggap wajib untuk produk SaaS multi-tenant.
Tantangan yang Muncul di Tengah Jalan
Nggak semua berjalan mulus. Beberapa hal yang saya revisi setelah versi awal:
- Timezone handling — awalnya saya simpan waktu tanpa timezone eksplisit, dan langsung bermasalah begitu ada tenant yang berbeda zona waktu. Solusinya pindah semua ke
timestamptzdan selalu eksplisit soal timezone di setiap query. - UX untuk cancel/reschedule — awalnya cancel booking cuma hapus row, tapi ini bikin history hilang. Saya ubah jadi soft-delete dengan status
cancelled, supaya masih bisa ditrack untuk keperluan reporting. - Notifikasi real-time — versi awal user harus refresh manual untuk lihat update status booking. Saya tambahkan Supabase Realtime supaya perubahan status langsung ter-reflect tanpa refresh.
Hasil Akhir
Fitur ini sekarang jadi salah satu modul paling stabil di ARES, dengan constraint database yang secara struktural mencegah konflik jadwal — bukan cuma mengandalkan validasi aplikasi yang bisa saja punya celah.
Yang paling saya pelajari dari proses ini: untuk masalah yang sifatnya "harus benar-benar konsisten" seperti mencegah double booking, jangan cuma andalkan validasi di kode aplikasi — manfaatkan constraint database yang secara desain memang dibuat untuk menjamin konsistensi data.
Penutup
Studi kasus ini cuma satu dari beberapa modul yang saya bangun di ARES — ada juga modul Catering (pemesanan makan lewat QR/RFID) dan Visitor Management yang punya tantangan tekniknya sendiri-sendiri, mungkin bisa jadi bahasan artikel terpisah lain kali.
Kalau kamu lagi butuh sistem booking, manajemen fasilitas, atau platform SaaS custom dengan kebutuhan spesifik seperti ini, saya buka jasa untuk itu. Cek studi kasus lengkap ARES di portofolio saya, atau hubungi lewat halaman Contact.
Ada pertanyaan soal implementasi teknisnya? Tulis di komentar, nanti saya bahas lebih detail.
Tidak ada komentar:
Posting Komentar