Introduction
I am a BS Artificial Intelligence student at UCP Lahore. My team and I are designing ParkEase, a system to solve urban congestion caused by parking searches.
We are currently in the architecture phase and looking for feedback on our logic and tech stack choices.
The Engineering Challenge
The core problem isn't just "finding a spot." It is handling data in a constrained environment:
- Connectivity: Parking basements in Lahore often have zero signal.
- Data Sync: How to sync payment data when the user comes back online.
- Concurrency: Handling real-time "Reserve" requests so two drivers don't book the same slot.
Proposed Architecture
1. The "Offline Wallet" Logic
To solve the connectivity issue, we are proposing a "Float-based" wallet:
- User pre-loads funds (e.g., 1000 PKR).
- Entry: Guard scans QR -> Timer starts (Local timestamp).
- Exit: Guard scans QR -> Timer stops -> Fee calculated locally on the Guard's device.
- Sync: Transaction uploads to Firebase once the Guard's device reconnects.
- Question for the community: Is this the safest approach to prevent fraud?
2. The "Hourly Block" Algorithm
We designed a billing algorithm to maximize revenue for owners. Instead of per-minute billing, we use "Hourly Blocks."
- Scenario: Enter 5:59 PM, Exit 6:01 PM.
- Logic: System detects occupancy in Block A (5-6) and Block B (6-7).
- Result: Billable time = 2 Hours.
The Tech Stack Choices
We are planning to build this using:
- Frontend: Flutter (for cross-platform consistency).
- Backend: Node.js (for scalable, non-blocking I/O).
- Database: Firebase Realtime Database (for the live map availability).
Request for Feedback
Since we are currently building the MVP, I would love to hear from senior engineers:
- Is Firebase the right choice for cost-scaling, or should we move to PostgreSQL + WebSockets?
- Are there security risks with the Offline Wallet approach we missed?
You can view our full project documentation here:
[https://github.com/miksi0078]
Building in public from Lahore, Pakistan.
Top comments (0)