Rencana Pembuatan Aplikasi Rentalin Backend

Rencana Pembuatan Aplikasi Rentalin Backend

Rentalin Backend dibangun untuk menjadi fondasi sistem rental yang profesional, stabil, dan mudah dikembangkan. Fokus utamanya bukan hanya menyelesaikan transaksi sewa secara cepat, tetapi juga memastikan arsitektur, data model, dan proses operasional siap dipakai dalam jangka panjang.
Dokumen ini merangkum arah pengembangan aplikasi secara end-to-end, mulai dari definisi kebutuhan bisnis, desain domain, rancangan API, model data, sampai strategi deployment dan pengujian. Pendekatan yang dipilih menekankan maintainability, efisiensi resource, dan kesiapan evolusi ke arsitektur multi-tenant.

Tujuan Produk

Rentalin dirancang untuk membantu operasional rental dengan alur yang jelas dan konsisten. Sistem harus mampu menangani inventaris, transaksi rental, perpanjangan, retur, denda keterlambatan, kerusakan barang, hingga pelaporan dasar.
Secara bisnis, tujuan utama aplikasi ini adalah:

• Menyederhanakan proses operasional rental harian.
• Mengurangi kesalahan pencatatan stok dan transaksi.
• Memberikan kontrol yang lebih baik terhadap status barang.
• Menyediakan audit trail untuk aktivitas penting.
• Menyiapkan pondasi teknis untuk pertumbuhan ke multi-product dan multi-tenant.

Prinsip Desain

Pengembangan Rentalin Backend mengikuti beberapa prinsip utama agar implementasinya tetap sehat dan tidak cepat menjadi rumit.

1. Domain Harus Jelas

Workflow inti seperti cek ketersediaan, pembuatan rental, serah-terima, retur, perpanjangan, dan penutupan transaksi harus didefinisikan secara tegas. Setiap status dan perpindahan status perlu dibatasi oleh aturan domain yang eksplisit.

2. Data Harus Siap Tumbuh

Struktur data tidak boleh terlalu spesifik ke satu jenis produk. Karena itu, model data dibangun di atas entitas generik seperti `products`, `product_items`, `rentals`, dan `rental_items`, sehingga sistem tetap relevan ketika kategori barang bertambah.

3. Operasional Harus Ringan

Target deployment berada pada lingkungan VM yang terbatas sumber daya, sehingga aplikasi harus hemat memori, efisien dalam query database, dan disiplin dalam timeout serta koneksi.

4. Keamanan dan Isolasi Harus Sejak Awal

Multi-tenancy tidak boleh ditambahkan belakangan sebagai tambalan. Tenant isolation, claim-based authorization, dan kebijakan akses data harus masuk dari awal agar migrasi ke skala lebih besar tidak mahal.

Arsitektur Aplikasi

Aplikasi akan memakai pendekatan clean architecture ringan agar batas tanggung jawab tiap lapisan tetap jelas.

Struktur Lapisan

• cmd/api untuk bootstrap aplikasi, konfigurasi, dan lifecycle server.
• internal/adapter/http untuk handler, middleware, dan mapping request-response.
• internal/usecase untuk orkestrasi proses bisnis.
• internal/domain untuk entity dan rule inti.
• internal/port untuk interface repository dan service boundary.
• internal/adapter/postgres untuk implementasi akses data.
• internal/platform untuk konfigurasi, logger, auth verifier, clock, dan generator ID.

Pendekatan ini menjaga dependensi tetap satu arah dan membuat perubahan pada infrastruktur tidak langsung merusak aturan bisnis.

Model Domain

Model domain disusun berdasarkan alur rental yang nyata. Entitas inti yang perlu disiapkan meliputi:

• tenants untuk isolasi data per organisasi.
• users dan tenant_memberships untuk otorisasi pengguna.
• categories dan products sebagai katalog master.
• product_items untuk unit fisik yang bisa disewa.
• rentals dan rental_items sebagai transaksi utama.
• fee_lines untuk denda dan biaya tambahan.
• extensions untuk perpanjangan manual.
• condition_reports untuk pencatatan kondisi barang.
• audit_logs untuk jejak aktivitas penting.

Dengan struktur ini, sistem tidak hanya mencatat transaksi, tetapi juga mampu menjelaskan konteks operasional di balik setiap perubahan status barang.

Alur Bisnis Inti

Ada enam alur utama yang menjadi inti aplikasi.

1. Cek Ketersediaan

Sebelum transaksi dibuat, sistem harus memastikan unit barang benar-benar tersedia pada rentang waktu yang diminta. Validasi ini mencegah double booking dan mengurangi konflik operasional.

2. Buat Transaksi Rental

Saat rental dibuat, sistem mencatat pelanggan, item yang disewa, tanggal mulai, tanggal jatuh tempo, serta kalkulasi harga awal. Proses ini harus deterministik dan mudah diuji.

3. Serah-Terima Barang

Ketika barang diserahkan, status item diperbarui dan kondisi awal dapat direkam. Langkah ini penting untuk memisahkan kondisi sebelum dan sesudah penyewaan.

4. Retur Barang

Saat barang kembali, sistem menilai apakah ada keterlambatan atau kerusakan. Late fee dan damage fee harus dipisahkan agar laporan dan penagihan lebih akurat.

5. Perpanjangan Manual

Perpanjangan tidak boleh otomatis tanpa kontrol. Sistem perlu memeriksa konflik jadwal, menghitung ulang biaya, dan mencatat persetujuan atau alasan perubahan.

6. Penutupan Transaksi

Transaksi dinyatakan selesai setelah semua item kembali, biaya akhir dihitung, dan status settlement ditetapkan. Pada tahap ini, seluruh biaya harus teragregasi dengan jelas.

Strategi Pricing

Untuk MVP, pricing disiapkan dalam bentuk tiered flat pricing agar fleksibel tanpa membuat sistem terlalu kompleks.
Aturannya sederhana:

• Harga bisa ditentukan per produk atau per kategori.
• Rule level produk memiliki prioritas lebih tinggi daripada rule level kategori.
• Jika tidak ada rule aktif, sistem fallback ke `base_price` produk.
• Struktur ini tetap mudah diuji dan tidak bergantung pada logika harga yang hardcoded.

Pendekatan ini memberi ruang untuk promo durasi sewa yang lebih lama tanpa mengorbankan konsistensi perhitungan harga.

API dan Keamanan

API akan dibangun sebagai REST endpoint yang dipisahkan per bounded context, misalnya untuk auth, tenant, katalog produk, inventory, rental, retur, fee, dan laporan.

Di sisi keamanan, beberapa hal harus menjadi standar:

• Verifikasi Supabase JWT dengan validasi signature, issuer, audience, dan expiry.
• Tenant context wajib diturunkan dari claim atau membership pengguna.
• Setiap query repository harus dipastikan scoped ke tenant yang benar.
• Endpoint kritikal perlu mendukung idempotency key agar aman dari request ganda.

Strategi Infra

Karena target deployment berada pada VM terbatas memori, pendekatan runtime harus hemat dan disiplin.

Yang diprioritaskan:

• Binary statis hasil multi-stage build.
• Image container minimal dan non-root user.
• Pool koneksi database yang konservatif.
• Timeout request yang ketat.
• Pagination untuk semua endpoint daftar data.
• Graceful shutdown untuk menjaga integritas koneksi saat deploy.

Dengan disiplin ini, aplikasi tetap responsif tanpa membebani server.

Observability

Observability dibuat ringan namun tetap berguna untuk operasional awal.
Komponen minimal yang disiapkan:

• Structured JSON logging.
• Request ID untuk pelacakan end-to-end.
• Endpoint metrics dasar.
• Monitoring memory, goroutine, dan koneksi database.

Tujuannya bukan membangun observability yang berat sejak hari pertama, melainkan menyediakan sinyal operasional yang cukup untuk deteksi masalah utama.

Roadmap Implementasi

Rencana implementasi dibagi ke dalam beberapa fase agar pekerjaan tetap terukur.

Phase A: Refinement Domain
Menetapkan workflow inti, status machine, aturan denda, perpanjangan manual, dan edge cases operasional.

Phase B: Arsitektur dan Infrastruktur
Menyusun boundary package, strategi efisiensi resource, containerization, CI/CD, dan observability minimum.

Phase C: Data Modeling
Menyelesaikan ERD, constraint, indexing strategy, dan struktur tabel yang tenant-ready.

Phase D: API dan Security
Menetapkan endpoint, format response, middleware auth, tenant enforcement, dan matriks otorisasi.

Phase E: Scalability
Menyiapkan evolusi ke multi-product, RLS, dan jalur scale-out infra bila beban meningkat.

Phase F: Verification
Menguji rule domain, integrasi repository, keamanan JWT, performa dasar, dan migrasi schema.

Kriteria Keberhasilan

Implementasi dianggap siap ketika beberapa kondisi berikut terpenuhi:

• Alur rental utama berjalan tanpa ambiguitas status.
• Data antar tenant terisolasi dengan benar.
• Perhitungan harga, denda, dan perpanjangan dapat diuji secara deterministik.
• API stabil di lingkungan resource terbatas.
• Proses build, test, dan deploy dapat direproduksi melalui CI/CD.

Penutup

Rentalin Backend tidak dibangun sebagai sekadar aplikasi rental biasa. Targetnya adalah sistem yang rapi secara domain, kuat secara arsitektur, dan realistis untuk dijalankan dalam environment kecil tanpa mengorbankan kualitas.
Dengan fondasi yang benar sejak awal, pengembangan fitur lanjutan seperti multi-product, multi-tenant yang lebih ketat, dan peningkatan observability akan jauh lebih mudah dilakukan di tahap berikutnya.