Roster

💡 Inspiration

In major metropolitan hubs across India and Southeast Asia, the informal hospitality workforce relies entirely on fragmented, word-of-mouth networks. Picture a bustling hotel in Bandra on a Saturday afternoon: they suddenly need two extra servers for a wedding banquet that evening. Their usual staffing agency requires a 24-hour lead time, and chaotic WhatsApp coordination groups rarely yield immediate, reliable results.

We wanted to bridge this gap by creating an instant, local matchmaker for urgent gig work, removing the friction of patchy informal infrastructure and allowing hospitality businesses to scale their workforce in real-time.

🚀 What it does

Roster is a real-time, zero-latency gig shift marketplace that pairs desperate venues with verified local workers instantly.

Venues use a clean web dashboard to broadcast urgent operational needs (specifying role, hourly pay rate, and exact time). Qualified workers within a strict geographical radius receive immediate push notifications via their mobile view. The platform operates on a hyper-fast, first-to-respond model: the moment the designated number of open slots are accepted, the shift locks down instantly, automatically rejecting subsequent attempts without crashing the system.

🛠️ How we built it

We built Roster using a decoupled, highly responsive architecture tailored for extreme real-time synchronization:

Database Engine: The core of the platform runs on Amazon Aurora DSQL. We integrated the @aws/aurora-dsql-node-postgres-connector to securely handle distributed transactions and automatic 15-minute IAM token rotations without static passwords.

Backend API: A Node.js and Express backend serves as the high-throughput transaction layer.

Frontend Portals: We built a Tailwind-styled Next.js application that serves two roles: a desktop dashboard for venues to monitor shift fulfillment in real-time, and a mobile-first UI for workers to instantly accept gigs.

🚧 Challenges we ran into

The defining architectural challenge was managing the concurrent acceptance race condition (the "Thundering Herd" problem).

When $N$ workers attempt to claim $S$ slots simultaneously (where $N \gg S$), the probability of a database write collision approaches $1$. In traditional databases, solving this requires explicit, pessimistic table locks (e.g., SELECT ... FOR UPDATE), which drastically reduces system throughput and causes connection queues to pile up.

Shifting our mental model to Aurora DSQL’s lock-free Optimistic Concurrency Control (OCC) was a major hurdle. We had to rethink state validation. Instead of locking the database, we wrote robust application-level logic to catch the SQLSTATE 40001 (Serialization Failure) exceptions thrown by the DSQL Adjudicator. We implemented a safe while(retries > 0) loop that intercepts the failure, re-reads the $S$ slots, and cleanly rejects excess workers without ever slowing down the database layer.

🏆 Accomplishments that we're proud of

We successfully engineered a production-grade, distributed transaction engine that completely eliminates double-bookings.

We validated our architecture by writing a custom Node.js stress-testing script that fired 50 simultaneous HTTP POST requests to our acceptance endpoint at the exact same millisecond. The system flawlessly processed the OCC conflicts: it committed the first 2 workers, triggered the correct backoff retries for the conflicting requests, and rejected the remaining 48 seamlessly without a single row lock or system hang.

🧠 What we learned

This project provided an incredible masterclass in distributed systems. Specifically, we learned:

The immense performance advantages of lock-free database architectures.

The inner workings of Optimistic Concurrency Control (OCC) and how an Adjudicator evaluates commit intents in a distributed cluster.

How to properly catch and handle concurrency exceptions at the API layer rather than the database layer.

The importance of using UUIDs instead of sequential IDs to prevent storage node hotspots in distributed systems.

🔮 What's next for Roster

We plan to scale Roster by implementing native GPS geofencing to automate worker check-ins upon physical arrival at a venue. Additionally, we intend to integrate a reliable worker rating system and explore dynamic surge pricing algorithms—adjusting hourly rates automatically as $S \to 0$ during peak weekend hours.