Kasus 1: Aset Rusak Berat di Tengah Masa Rental (Mid-Rental Breakdown)¶
Skenario: Mobil mogok di luar kota atau kamera mati mendadak saat sesi pemotretan pernikahan.
Penanganan:
Pelanggan tekan tombol darurat (Emergency Button) di app.
Sistem ubah status aset ke DAMAGED, freeze sisa hari sewa di bitmask Redis.
App mencarikan unit pengganti setara (SKU sama) dari cabang terdekat dalam radius 50 km.
Jika tidak ada unit setara → refund proporsional sisa hari penyewaan yang tidak terpakai, dibayarkan langsung lewat escrow e-wallet.
Aset rusak dimasukkan ke antrian maintenance_logs dengan flag EMERGENCY_REPAIR.
Kasus 2: Pelanggan Mengabaikan Jatuh Tempo & Melarikan Unit (Asset Theft)¶
Skenario: Pelanggan tidak mengembalikan kendaraan setelah H+1, ponsel tidak aktif, GPS dimatikan paksa.
Penanganan:
H+1 Jam: Sistem kirim WhatsApp blast penagihan otomatis setiap 30 menit.
H+5 Jam: Deposit di-capture 100% (pre-auth jadi debet penuh), status rental → DISPUTED.
H+24 Jam: Sistem generate dokumen kronologis hukum (PDF Digital Agreement + riwayat verifikasi KTP/selfie + log GPS terakhir sebelum mati) untuk pelaporan ke kepolisian.
Alert ke Field Recovery Team dengan detail identitas lengkap pelanggan.
Kasus 3: Redis Lock Expired Sebelum Pembayaran Selesai¶
Skenario: Pelanggan A mengunci aset, melakukan pembayaran via transfer bank, namun proses konfirmasi bank memakan waktu > 10 menit (TTL Redlock habis).
Penanganan:
Setelah TTL habis, sistem mencoba re-acquire lock sebelum memproses webhook pembayaran.
Jika lock berhasil di-acquire (tidak ada pelanggan B yang mengambil) → lanjut proses booking.
Jika lock tidak bisa di-acquire (pelanggan B sudah memesan) → refund otomatis ke pelanggan A + notifikasi WhatsApp. Tampilkan unit alternatif SKU sama yang tersedia.
Kasus 4: Partial Upload Failure (Inspector Mobile Offline → Online)¶
Skenario: Inspector upload 8 foto check-out, koneksi putus saat foto ke-5. 4 foto sudah di S3, 4 belum.
Penanganan:
App mencatat progress upload di local SQLite: { photo_id, s3_url, uploaded: boolean }.
Saat koneksi pulih, background worker hanya meng-upload foto yang uploaded: false.
Setelah semua 8 foto berhasil → baru server generate tamper_proof_hash dan finalisasi inspection record.
Booking tidak dapat berstatus DISPATCHED sebelum semua foto berhasil diupload dan hash direkam.
Kasus 5: Bitmask Redis Tidak Sinkron dengan PostgreSQL (Cache Drift)¶
Skenario: Redis cluster crash dan restart tanpa data persistence; bitmask hilang sementara data booking di PostgreSQL masih ada.
Penanganan:
Saat Redis restart, sistem menjalankan RebuildCalendarCacheJob — membaca semua booking aktif dari PostgreSQL dan merekonstruksi bitmask Redis.
Selama rekonstruksi (estimasi < 2 menit), endpoint GET /availability dikembalikan dari PostgreSQL langsung (fallback mode).
Booking endpoint POST /bookings ditolak sementara dengan error SERVICE_TEMPORARILY_UNAVAILABLE untuk mencegah double booking saat cache sedang dibangun ulang.
Kasus 6: Pelanggan Mengklaim Kerusakan Sudah Ada Sebelumnya (False Damage Dispute)¶
Skenario: Saat check-in, inspector menemukan goresan baru. Pelanggan mengklaim goresan sudah ada saat check-out.
Penanganan:
Admin menarik foto check-out dari S3 (immutable, SHA-256 verified).
Jika foto check-out menunjukkan tidak ada goresan → Damage Tariff Matrix berlaku, deposit di-capture.
Jika foto check-out ternyata sudah menunjukkan goresan (inspector kelalaian dokumentasi) → denda dibatalkan, deposit di-release penuh, inspector kena Penalty Deduction Rp 200.000.