Database Documentation

Overview

RentOne uses MongoDB 7.0.31 as the primary database across all backend microservices.

The platform follows a multi-tenant architecture — each tenant is assigned a dedicated MongoDB database. All tenant-scoped operations are routed to the correct database at runtime using the X-Tenant-Header on every request. A separate shared database holds the central tenant registry.

Architecture

Multi-Tenant Database Model

┌─────────────────────────────────────────────────────────┐
│                  Shared Registry DB                      │
│  Collections: rentone_tenants, db_sequence               │
└─────────────────────────────────────────────────────────┘

┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│   DB: RENTONE    │  │   DB: DEVMINDS   │  │   DB: <TENANT>   │
│  tenants_users   │  │  tenants_users   │  │  tenants_users   │
│  users           │  │  users           │  │  users           │
│  orders          │  │  orders          │  │  orders          │
│  products        │  │  products        │  │  products        │
│  ...             │  │  ...             │  │  ...             │
└──────────────────┘  └──────────────────┘  └──────────────────┘

Each tenant database is a complete, isolated copy of all service collections. No data is shared between tenant databases.

Tenant Routing

Every inbound API request must include the tenant identifier header:

X-Tenant-Header: RENTONE

The Tenant Service resolves the corresponding MongoDB connection string and all subsequent queries in that request target that tenant's database exclusively.

Known Tenant Databases

Tenant	Database
`RENTONE`	`RENTONE`
`DEVMINDS`	`DEVMINDS`

Shared Registry Database

The shared database is independent of any tenant. It is accessed directly by the Tenant Service to bootstrap tenant resolution.

`rentone_tenants`

Stores the registry of all registered tenants.

Field	Type	Key	Description
`tenantId`	String	PK	Unique tenant identifier (always uppercase)
`mongoURL`	String		MongoDB connection string template for the tenant
`creationDate`	Date		Timestamp when the tenant was registered
`enabled`	Boolean		Whether the tenant is active and can process requests

Notes:

tenantId is the routing key used by all services
mongoURL contains a placeholder ({tenant}) replaced at runtime with the actual tenant name
If enabled is false, all requests for that tenant are rejected with 401 Unauthorized

`db_sequence`

Auto-increment counter store for ID generation across the platform.

Field	Type	Key	Description
`id`	String	PK	Name of the sequence (e.g. `user_seq`)
`seq`	Long		Current counter value; atomically incremented on every read

Notes:

Uses MongoDB findAndModify with upsert: true — the counter is created on first access
Returns the post-increment value

Tenant Service Collections

These collections exist inside each tenant's dedicated database and are managed by the Tenant Service (backend-rentone-tenants, port 6003).

`tenants_users`

Stores tenant administrator accounts. Each record represents a user who can log in to the RentOne admin console for that tenant.

Field	Type	Key	Description
`email`	String	PK	User's email address; serves as the login username
`tenantId`	String	FK	References `rentone_tenants.tenantId`
`tenantUserName`	String		Display name shown in the UI
`profileImage`	String		URL to the user's profile image
`password`	String		BCrypt hash of `(rawPassword + salt + pepper)` — never returned in API responses
`randomSalt`	String		Base64-encoded 128-bit cryptographically random salt, unique per user
`userTypes`	Enum		User role (e.g. `SUPER_ADMIN`)
`accessLevel`	Map		`UniqueAccessControlGroup → ACGAccessLevel` permission map embedded in JWT
`lastLogin`	Date		Timestamp of the most recent successful login
`createdDate`	Date		Account creation timestamp

Notes:

password and randomSalt are never returned in any API response
accessLevel is sourced from the Cloud App Service at creation time based on userTypes
A SUPER_ADMIN user cannot be deleted — enforced at the service layer
lastLogin is updated on every successful authentication

User Service Collections

Managed by backend-rentone-users (port 6005).

`users`

Stores end-user (customer) accounts.

`user_kyc`

Stores Know Your Customer verification documents and status for users.

`refresh_tokens`

Stores active refresh tokens for user session management.

Product Catalog Collections

Managed by backend-rentone-product-catalog (port 6006).

`product_categories`

Stores the hierarchy of product categories used to organise the catalog.

`products`

Stores the master product records (name, description, media, pricing, category).

`product_variants`

Stores variant-level details for products (e.g. size, colour, configuration).

`packages`

Stores rental package definitions associated with products.

`variants_stat`

Stores aggregated statistics and metrics at the variant level.

Commerce Service Collections

Managed by backend-rentone-commerce-service (port 6008).

`orders`

Stores all customer rental orders, their status, and lifecycle events.

`user_carts`

Stores active shopping cart state per user.

`users_wishlist`

Stores user-saved wishlist items.

`invoices`

Stores generated invoices linked to orders.

`addresses`

Stores customer delivery and billing addresses.

Inventory System Collections

Managed by backend-rentone-inventory-system (port 6007).

`inventory_items`

Stores individual physical inventory units, their condition, and assignment status.

`warehouses`

Stores warehouse locations and their associated metadata.

`inventory_transactions`

Stores a log of all inventory movements (inbound, outbound, transfers, returns).

Operation Service Collections

Managed by backend-rentone-operation-service (port 6013).

`maintenance_requests`

Stores maintenance and repair requests raised against inventory items.

`return_requests`

Stores product return requests initiated by customers or operations staff.

Collection Ownership Summary

Collection	Service	Database Scope
`rentone_tenants`	Tenant Service	Shared Registry
`db_sequence`	Tenant Service	Shared Registry
`tenants_users`	Tenant Service	Per-Tenant
`users`	User Service	Per-Tenant
`user_kyc`	User Service	Per-Tenant
`refresh_tokens`	User Service	Per-Tenant
`product_categories`	Product Catalog	Per-Tenant
`products`	Product Catalog	Per-Tenant
`product_variants`	Product Catalog	Per-Tenant
`packages`	Product Catalog	Per-Tenant
`variants_stat`	Product Catalog	Per-Tenant
`orders`	Commerce Service	Per-Tenant
`user_carts`	Commerce Service	Per-Tenant
`users_wishlist`	Commerce Service	Per-Tenant
`invoices`	Commerce Service	Per-Tenant
`addresses`	Commerce Service	Per-Tenant
`inventory_items`	Inventory System	Per-Tenant
`warehouses`	Inventory System	Per-Tenant
`inventory_transactions`	Inventory System	Per-Tenant
`maintenance_requests`	Operation Service	Per-Tenant
`return_requests`	Operation Service	Per-Tenant

Backup and Restore

Create a Full Backup

mongodump --out backup/

Create a Backup for a Specific Tenant Database

mongodump --db RENTONE --out backup/

Restore a Full Backup

mongorestore backup/

Restore a Specific Database

mongorestore --db RENTONE backup/RENTONE/

Developer Notes

Never query across tenant databases — all repositories are scoped by the X-Tenant-Header resolved at request time
The tenantId field present on per-tenant documents (e.g. tenants_users.tenantId) is a redundancy for query filtering within the tenant DB — it mirrors the database name
db_sequence uses atomic findAndModify with upsert: true — it is safe for concurrent access
The mongoURL in rentone_tenants is a template string. The placeholder is substituted with the tenant name at runtime before establishing the connection
MongoDB indexes are not defined at the application layer in the current codebase — ensure appropriate indexes are created manually on production for high-traffic collections (e.g. tenants_users.email, orders, inventory_items)