NeuPool

1. Overview

NeuPool is a carpooling coordination platform for universities and large organisations. The idea came out of seeing how much friction there is around organising shared rides to events, whether that is a game, a conference, or a campus commute. Most solutions are either too informal (a group chat) or too consumer-focused (Uber) to work well for recurring, community-driven carpooling.

NeuPool gives groups the tools to organise rides properly: role-based group management, a built-in chat, push notifications, and automated gas cost splitting through Stripe. It is currently piloting at Northeastern University, with a wider release targeting Fall 2026.

2. System Architecture

NeuPool is a Go modulith deployed on AWS. Running it as a single deployable unit keeps infrastructure costs low while the product is still in pilot. The codebase is structured internally so that individual modules (matching, chat, payments, notifications) can be extracted into separate services if the load justifies it.

The backend runs on EC2, with RDS for PostgreSQL as the primary database, ElastiCache for session and group state caching, and Amazon SQS for decoupling event processing from the request path.

3. Ride Matching

Ride matching is the core computational challenge. When a match request comes in, the system needs to find the optimal assignment of riders to drivers given pickup locations, route overlap, seat capacity, and timing constraints.

NeuPool uses Google OR-Tools for this, which frames the assignment as a vehicle routing problem and solves it with a constraint satisfaction approach. Go's native concurrency handles 1,000+ simultaneous matching requests by running each match job in its own goroutine, so requests do not queue behind each other.

4. Key Features

• RBAC group management: organisations create groups with role-based access. Admins manage members, set event details, and configure carpool rules. Members see only what is relevant to them.
• WebSocket-based in-app chat: real-time chat within carpool groups, built on persistent WebSocket connections managed by the Go backend.
• Push notifications: match confirmations, ride reminders, and chat notifications sent through the notification worker.
• Gas cost splitting via Stripe: once a ride is completed, the platform calculates each rider's share of the gas cost and initiates the payment split through Stripe.
• Optimal ride matching: Google OR-Tools assigns riders to drivers to minimise total route distance while respecting seat capacity and timing constraints.

5. Engineering Trade-offs

• Modulith over microservices: at pilot scale, a modulith avoids the networking, deployment, and observability overhead that microservices introduce. The internal module boundaries make future extraction straightforward without committing to the operational cost prematurely.
• SQS over Kafka: NeuPool's event patterns are simple: a match fires a notification, a payment completes and triggers a receipt. There is no need for event replay or multiple independent consumers reading the same log. SQS is cheaper, simpler, and honest about the actual requirements.
• OR-Tools over a custom algorithm: vehicle routing is a well-studied NP-hard problem. OR-Tools provides a production-quality solver maintained by Google with strong constraint handling. Writing a custom heuristic would have taken significantly longer and likely produced worse results.
• PostgreSQL for everything: rider locations, group membership, ride history, payment records. The relational model fits all of these cleanly. A hybrid approach with a separate spatial or document store would have added complexity without a clear benefit at this scale.