v1.0: Driver Location Tracking, AWS Cloud Deployment & Remote Load Testing

This major release marks the platform's expansion into a production-grade cloud environment. It delivers the final real-time tracking feature, extends the system with a fully automated AWS deployment that runs alongside the existing local environment, introduces a remote load-testing setup, and consolidates a substantial round of quality improvements and bug fixes across the whole application.

🚚 Real-Time Driver Location Tracking

• Live Position Broadcasting: Delivery drivers now continuously broadcast their geographic position over their dedicated WebSocket channel while on route. Each ping is validated server-side and persisted only when the location has actually changed from the last one, keeping network traffic and database writes to a minimum.
• Customer Live Tracking: Once an order enters the delivery phase, customers can follow the approximate location of the assigned truck on an interactive real-time map, together with the recommended route to the destination and an estimated time of arrival.
• Controlled Tracking Lifecycle: Position tracking is strictly tied to the driver's active session: it starts when the driver connects and stops cleanly when the connection closes, preserving the last known position so the information remains consistent between routes.

☁️ AWS Cloud Deployment

• Serverless Container Orchestration: In the cloud, the application runs on Amazon ECS Fargate, executing the unified Docker image across multiple instances without managing any underlying servers, with images distributed through Amazon ECR.
• Managed Data Layer: In the cloud, the platform runs on managed services — Amazon RDS for the relational data and Amazon DocumentDB for usage data and real-time events — with multimedia assets served from Amazon S3. Rather than replacing the local stack, a storage and service abstraction lets the same artifact point to the local databases and MinIO during development, or to the managed AWS services in production, selected purely through environment variables. The cloud services reused the existing code with minimal changes, adding specific adaptations where DocumentDB diverges from MongoDB.
• Global Distribution & Edge: Public access is handled through Amazon CloudFront with TLS termination and a custom domain managed by Route 53, with certificates provisioned and renewed automatically via AWS ACM. Cache behavior is tuned per content type, disabling it for the API and WebSocket routes while optimizing delivery of the static frontend.
• Network Isolation & Security: All components critical to the system run inside private subnets with no direct internet access, reachable only through the load balancer. AWS WAF filters malicious traffic at the edge, IAM least-privilege roles govern every internal communication, and Secrets Manager injects all sensitive values at startup, never exposing them in the code or logs.
• External Services via Lambda: Geocoding, routing, and Google authentication are proxied through dedicated AWS Lambda functions, and transactional email is delivered through Amazon SES, keeping the application instances fully isolated from the public internet.
• Infrastructure as Code: The entire environment is defined as CloudFormation nested stacks, making the whole infrastructure reproducible, version-controlled, and recoverable from scratch. See the AWS Architecture page for the full design.

📈 Remote Load Testing

• Traffic-Shaped Scenarios: A k6-based load-testing suite reproduces real usage patterns — anonymous browsing, authenticated client journeys, WebSocket presence, and staff dashboards — running together to mirror the platform's actual traffic mix, with authentication handled entirely through cookies just like the real SPA.
• Configurable Load Profiles: Several profiles cover different goals, from a quick sanity check to a sustained baseline, an endurance run, and a staged ramp specifically designed to trigger consecutive scale-out events.
• Autoscaling Validation: The tests deliberately push the system past its CPU scaling threshold to confirm that new instances are added automatically, absorb the incoming load, and bring latency back within the defined SLOs.
• Dedicated Parallel Environment: All tests run against an isolated, disposable clone of the platform restored from production snapshots, guaranteeing realistic data while never touching the live environment, enforced by a hard guard in the test script.

✅ Quality & Stability

• Multi-Replica Coordination: The notification and presence systems were adapted to operate correctly across multiple simultaneous instances, relying on DocumentDB change streams and load-balancer session affinity to deliver events to the right user without duplicates or cross-instance coordination.
• Resilient Real-Time Connections: The frontend now reconnects automatically with exponential backoff when a WebSocket connection drops — whether due to a scale-in event or an edge timeout — recovering any updates missed during the interruption.
• Concurrent-Safe Data Seeding: The startup data initialization was made safe for multiple instances booting at once, preventing duplicate inserts by letting the database act as the natural arbiter of concurrency.
• Expanded Test Coverage: The automated test suites for both backend and frontend were substantially extended, maintaining high coverage and reliability standards under continuous static analysis with SonarQube.
• Bug Fixing & Refinements: A wide round of error corrections and refinements across the platform closes the development cycle, improving the overall robustness and consistency of the application.