960 B
Attachment Storage Strategy
Status: accepted
The application needs to store files such as invoices, signed lease contracts, and check-in/check-out photos. We have decided to store the actual binary files on the server's local file system (mounted as a persistent Docker volume) rather than storing them directly in MongoDB (e.g. via GridFS) or utilizing external cloud object storage. MongoDB will only store file metadata (local file path, file name, MIME type, size). This ensures optimal performance for serving files while keeping the configuration simple.
Tenant attachment deletion first moves files into private staging and retains recoverable filesystem links until the MongoDB metadata change is committed. Cleanup files left after that commit are recognizable tombstones and are retried on startup and later storage operations, so a filesystem failure does not produce active orphan files or roll back a deletion that has already committed.