Case studyProduction

GoParkEasy Platform

A production-grade SaaS parking platform — 450+ REST APIs across a 51-collection schema, 5+ role-based access tiers, and a real-time availability engine processing 100 events every 5 seconds.

Role
Full-Stack Engineer · GoParkEasy
Timeline
Aug 2025 – Nov 2025
Links
Visit Proprietary
Next.js 15Node.jsMongoDBRedis StreamsSocket.ioPuppeteer
450+
REST APIs
51
collection schema
5+
role-based tiers
+15%
operational throughput
01

The problem

Running parking operations at scale means a lot of moving parts — bookings, availability, check-ins, payments, and multiple kinds of users (customers, valets, operators, admins) who each need a different view and different permissions.

It needed to be built from the ground up as a real product, not a prototype: a coherent data model, hundreds of endpoints, and access control that holds up across roles.

And availability had to feel live. A spot that's already taken can't still show as free, so status had to propagate in real time rather than on a polling delay.

02

The approach

I architected the platform on Next.js 15, Node.js, and MongoDB — defining a 51-collection schema and delivering 450+ REST APIs with 5+ role-based access tiers so each user type only sees and does what they should.

A real-time availability engine built on Redis Streams and Socket.io pushes status changes to clients as they happen, processing roughly 100 events every 5 seconds.

Check-in runs through a QR-based system generated with Puppeteer, and I resolved MongoDB indexing bottlenecks across the 51 collections to keep queries fast as the data grew.

03

Architecture

Platformcore
Next.js 15 app
client + SSR
Node API layer
450+ REST endpoints
Role-based access
5+ tiers
MongoDB
51-collection schema
Realtimelive
Availability events
~100 / 5s
Redis Streams
event log
Socket.io
push to clients
QR check-in
Puppeteer-generated

// Indexing tuned across 51 collections to keep queries fast; availability propagates over Redis Streams instead of polling.

04

How it's built

  • Designed a 51-collection MongoDB schema and delivered 450+ REST APIs on Next.js 15 and Node.js, with 5+ role-based access tiers enforced across endpoints.
  • Built a real-time availability engine with Redis Streams and Socket.io processing ~100 events every 5 seconds, eliminating polling.
  • Shipped a QR-based check-in system generated with Puppeteer.
  • Profiled and resolved MongoDB indexing bottlenecks across the 51 collections, boosting operational throughput by 15%.
05

The outcome

A production SaaS platform with 450+ REST APIs and role-based access that scales across customers, valets, and operators.

Availability stays live via Redis Streams and Socket.io, so customers never book a spot that's already gone.

Indexing work boosted operational throughput by 15%, and the platform became the foundation the ParkBuddy assistant now runs on top of.

Next case study
ParkBuddy
RAG support bot for GoParkEasy

Want the deep dive?

Happy to walk through the design decisions and trade-offs.