RENTWHEELS: Fleet Orchestration and Relational State Management

00. TRANSMISSION OBJECTIVE

Managing a decentralized physical asset (a vehicle fleet) requires a rigid, transactional data layer. RENTWHEELS was engineered as a full-stack orchestration system to handle concurrent booking workflows, role-based access control (RBAC), and automated compliance reporting.

The objective was to bypass high-level ORM abstractions and build a strict, three-tier architecture relying on raw relational data integrity and session-based state management.

---

01. SYSTEM ARCHITECTURE

The infrastructure enforces a rigid separation of concerns across three distinct layers:

• PRESENTATION LAYER: HTML5 / CSS3 / Bootstrap 5. Edge-rendered interfaces for client interaction and administrative dashboards.
• BUSINESS LOGIC LAYER: Python Flask. Chosen explicitly for its microframework architecture, allowing granular control over route handlers and middleware without the monolithic bloat of Django.
• PERSISTENCE LAYER: Microsoft SQL Server. Interfaced via PyODBC. Optimized for enterprise-grade relational integrity and transactional safety.

---

02. INFRASTRUCTURE & FRICTION PROTOCOLS

A. Role-Based Access Control (RBAC) Architecture

• The Anomaly: Maintaining parallel authentication pipelines for standard users and system administrators introduces security vulnerabilities and code duplication.
• The Execution: Engineered a unified authentication matrix. Instead of isolated database tables, authorization is handled via an is_admin BIT flag within the core Users table. Flask session objects dynamically parse this flag at the middleware level, gating restricted routes (/admin/*) and immediately redirecting unauthorized payloads.

B. Relational Data Integrity & Normalization

• The Anomaly: Initial data schemas allowed orphaned booking records and data duplication, corrupting the booking state.
• The Execution: Enforced strict Third Normal Form (3NF) relational mapping. Implemented hard foreign-key constraints routing the Bookings table dynamically to both Users and Cars. A booking transaction cannot be written to disk unless both parent entities explicitly exist and validate.

C. Asset Storage Optimization

• The Anomaly: Storing high-resolution vehicle telemetry images as BLOBs directly inside SQL Server spiked database I/O latency and bloated backup sizes.
• The Execution: Decoupled media from the database. SQL Server now only stores lightweight URI string pointers (image_url), while the physical assets are routed and served directly from the static directory (static/images/cars/).

D. Server-Side Compliance Generation

• The Anomaly: Client-side invoice generation is susceptible to DOM manipulation and data spoofing.
• The Execution: Shifted document rendering entirely to the backend. Utilized ReportLab to dynamically compile immutable PDF invoices. The system pulls validated transaction data directly from SQL Server, rasterizes the PDF in memory, and serves the binary payload to the client upon booking completion.

---

03. DEPLOYMENT STATE

The core orchestration engine is stable. Future architectural upgrades will focus on migrating session states to JWT (JSON Web Tokens) for stateless REST API interactions, and containerizing the Flask environment via Docker for distributed cloud deployments.

---

// END OF TRANSMISSION
// RENTWHEELS :: https://github.com/maheshvyas-01/RentWheels
// STATUS     :: STABLE / V2.0 PENDING