Shuttle: High-Concurrency Transit Reservation System
A scalable booking engine handling high-concurrency seat reservations across web and mobile platforms.
Rationale
Why ShuttleNow? ShuttleNow is a real-time ticket booking app I built using the MERN stack. The biggest technical hurdle was handling high concurrency, what happens if two people try to book the exact same seat at the exact same second? To handle sudden spikes without crashing, I needed absolute control over the concurrency layer. By architecting a custom engine with Redis 'seat locking', I prevented about 95% of those double-booking conflicts.
Tech Stack
Core Engineering Challenge
The Bottleneck: Relying on standard database queries (MongoDB) for transient state (like a user simply clicking a seat) introduces latency and hammering the DB causes race conditions.
The Solution
I decoupled the data layer. I built a dedicated WebSocket server utilizing an in-memory state object for "soft locking." When User A clicks a seat, the Node server instantly broadcasts that lock to User B via Socket.IO before a database write ever occurs.
The Trade-off
By keeping transient state in memory, I traded higher Node server memory overhead for a massive reduction in database load and near-zero latency for the end user. MongoDB is strictly reserved as the final source of truth upon successful Stripe checkout.
Key Highlights
- ▹Reduced double-booking conflicts by 95% during burst traffic events by architecting a booking engine utilizing Redis Distributed Locks (Redlock) and Optimistic Concurrency Control (OCC).
- ▹Secured PCI-compliant payments across React web and React Native mobile interfaces by integrating Stripe API webhooks within serverless functions for asynchronous verification.
- ▹Scaled real-time inventory updates to 1,000+ concurrent clients with MongoDB versioning to manage seat inventory state.
- ▹<50ms latency achieved by integrating WebSockets for bidirectional state synchronization.
Architecture Details
Handling thousands of concurrent users trying to book the exact same transit seat requires stringent concurrency guarantees.
1. Redis Seat Locking
- As soon as a user selects a seat, a Distributed Lock is acquired in Redis. It locks it for a few minutes, temporally "holding" the inventory and preventing other active sessions from progressing past the checkout screen for the exact same seat.
2. Stripe PCI Verification
- For payments, I didn't want to handle sensitive data directly on my server. I integrated Stripe using AWS Lambda serverless functions to keep everything secure, asynchronous, and strictly PCI-compliant.
3. Unified Frontend & CI/CD
- Since users are heavily on mobile, I used a unified UI approach with React and React Native so the experience is perfectly smooth across devices.
- The entire system is bound to a full CI/CD pipeline on AWS Amplify, automatically building and updating the live site upon code push.
Interactive System Design
Unified Multi-Platform Client
Engineering Insight
Provides distinct user portals and responsive Admin dashboards. Embeds live interactive seat layout maps synced perfectly to state.