DEV Community: Inside GusLift

Week 6: How GusLift Matches Rides in Real Time

Abdul-Salam Zakaria — Sun, 15 Mar 2026 13:41:03 +0000

Every school morning, a few drivers leave their dorms for campus, and a bunch of riders need seats. The core problem: match them fast, in the right direction, before the window closes.

Here's how the matching engine actually works.

The Matching Room Abstraction

We don't run one global pool. We partition by location, day, and departure time. A room key looks like:

Westie:mon:08:00

That string becomes the identity of a Cloudflare Durable Object(DO), a live, in-memory process that owns all real-time state for that slot. Everyone heading from Westie at 8am Monday shares one room. Leaving at 10:30? Different room entirely. This keeps each instance small and focused. The matching room doesn't know or care about any other departure window.

Getting Into the Right Room

When a user opens the app, a Cloudflare Worker handles the request. It authenticates, resolves the user's schedule, generates the slot key, and forwards the WebSocket connection to the right DO. The Worker is stateless, purely a router. All the interesting state lives in the object it points to.

What the DO Tracks

Four things:

drivers — map of driver ID → seats remaining
riders_waiting — FIFO queue of riders requesting a ride
pending_matches — riders a driver has selected but who haven't confirmed
connections — live WebSocket handles, one per user

Every state change broadcasts to all connected clients. The frontend is a mirror of what the DO holds, nothing more.

The Flow

Driver goes online → sends driver_online with seat count → registered in the room, broadcast to everyone. Rider wants a seat → sends rider_request → added to the queue.

Driver picks someone. That rider moves out of riders_waiting into pending_matches and gets a match_request pushed to their socket. They have 30 seconds to accept. No response → back to the queue. They accept → seat decrements, ride written to Postgres, room updates for everyone.

The part that could get hairy is concurrent events — two drivers selecting the same rider at the same time. The DO's single-threaded execution model handles that without any extra locking. One message at a time, in order. It's one of the legitimately nice properties of this architecture.

Why Durable Objects

Serverless and WebSockets are a bad pairing by default. Serverless assumes requests are stateless and short-lived; a WebSocket is neither. DOs give you a persistent, single-threaded process with in-memory state that survives across events. For a campus app where load is concentrated in a 20-minute morning window, you get rooms that spin up when needed and hibernate when not. No idle infrastructure, no connection hand-off problems.

What's Left

A few open problems the current design doesn't address: drivers who cancel after a match is accepted, rooms that never get cleaned up after their departure window passes, and rate limiting on socket events. None of these tasks is difficult in principle. They just weren't the initial challenges.

Week 5: Improving Session Persistence and Planning Cross-Platform Support

SundeepShrestha — Sat, 07 Mar 2026 00:39:33 +0000

Last week, we introduced GusLift and focused on building the authentication system that allows users to log in using their Google accounts. This week, we continued working on improving how user sessions are handled within the app and started planning how the application will support multiple platforms.

Our main focus was improving session persistence and thinking about how the platform will eventually run across iOS, Android, and web environments.

Improving User Session Management

One challenge that often appears in mobile applications is how to handle user sessions after authentication. Ideally, users should not have to log in every time they open the app, but at the same time, sessions should not remain active indefinitely for security reasons.

To address this, we implemented Async Storage to store user session data locally on the device.

When a user successfully signs in using Google authentication, key information about the session is saved locally. This allows the application to recognize returning users and automatically keep them logged in.

Currently, sessions are configured to remain active for approximately seven days before requiring the user to authenticate again.

This approach improves usability while still maintaining a reasonable level of account security.

Why Async Storage Matters

Async Storage allows the app to persist small pieces of information locally on a user’s device.

In the case of GusLift, it is used to store session-related information so that users can continue using the app without repeatedly signing in.

Without this feature, every time a user closed and reopened the application, they would need to authenticate again, which would make the experience frustrating.

By storing session data locally, the app can restore the user's session quickly when the application launches.

Planning Cross-Platform Support

Another goal for the GusLift project is ensuring that the application can run across multiple platforms.

Since the project is being built using React Native with Expo, we have the flexibility to target several environments with a single codebase.

Our long-term objective is to support:

iOS devices
Android devices
Web browsers

Supporting multiple platforms increases accessibility and allows users to interact with the platform in whichever way is most convenient.

Why Cross-Platform Development Matters

Building separate applications for each platform can significantly increase development time and maintenance complexity.

Using React Native allows the team to reuse much of the same codebase across different environments, which simplifies development and makes future updates easier to manage.

This approach also allows us to test features more quickly as the project continues to evolve.

Next Steps

With authentication and session persistence in place, the next stage of development will focus on building the core functionality of the platform.

Some of the next milestones include:

Designing the ride request workflow
Implementing driver availability
Building the ride matching logic
Improving the user interface

As the project progresses, we will continue documenting the development process and technical decisions in these weekly updates.

Final Thoughts

The improvements made this week help create a smoother user experience by allowing users to remain logged in while also preparing the application for broader platform support.

Although the project is still in the early stages, these foundational components will make it easier to build the core ride-sharing functionality in the coming weeks.

Week 4: Understanding what GusLift Is

SundeepShrestha — Sat, 07 Mar 2026 00:09:31 +0000

Many students at Universities or Colleges rely on friends, rideshare services, or campus transportation to get around. While services like Uber and Lyft exist, they are not always practical for short trips around campus or nearby areas.

For example, a student might need a ride from their dorm to an academic building, a nearby apartment, or a grocery store. In situations like this, requesting a full rideshare service often feels unnecessary or expensive.

GusLift started as an idea to solve this problem by creating a campus-focused ride-sharing platform designed specifically for students.

The goal is simple: Make it easier for students to connect with others who are already driving somewhere nearby, while keeping the platform limited to trusted users within the college community.

The Idea Behind GusLift

Unlike traditional ride-sharing apps that are open to anyone, GusLift is designed to be restricted to verified users from the campus community.

This approach helps create a safer and more trusted environment where students know they are interacting with other members of their school community.

Instead of requesting rides from strangers, users can connect with other students who are already heading in the same direction.

The long-term goal is to create a small, efficient transportation network within the campus ecosystem.

Early concept for the GusLift interface.

What We Built So Far

This week, we focused on setting up the authentication system for the application.

Authentication is an important part of GusLift because the platform needs to ensure that only approved users can access the app.

To accomplish this, we implemented Google Sign-In.

This allows users to log into the application using their Google accounts instead of creating new usernames and passwords. Using Google authentication simplifies the login process while also providing a reliable identity verification system.

Google authentication is used to verify users during login.

Keeping Users Logged In

After implementing login functionality, the next step was making sure users do not have to sign in every time they open the app.

To solve this, we implemented Async Storage, which allows the application to store small pieces of data directly on the user's device.

Once a user logs in successfully, their session information is saved locally. This allows the app to recognize returning users and automatically keep them signed in.

Currently, user sessions are stored for seven days, after which the user will be asked to authenticate again.

await AsyncStorage.setItem( "@user", JSON.stringify({ ...data, savedAt: Date.now() }) );

This approach improves usability while still maintaining basic security.

Technologies Used

The current version of GusLift is being built using the following tools:

React Native (Expo) for cross-platform mobile development
Google Authentication for user login
Async Storage for storing session information locally

These tools allow us to rapidly prototype features while maintaining flexibility for future expansion.

What Comes Next

In the coming weeks, we plan to continue expanding the foundation of the app.

Some of the next steps include:

Improving how user sessions are handled within the application
Expanding support across multiple platforms
Beginning development of the core ride-sharing functionality

One of the long-term goals for the project is to make GusLift available across iOS, Android, and web platforms, allowing users to access the system from different devices.

Final Thoughts

GusLift is still in the early stages of development, but the core authentication system now provides a starting point for building the rest of the platform.

As development continues, the focus will shift toward building the features that actually enable users to request and offer rides.

Future posts will document the progress of the project as we continue building and testing new components of the system.