FleetPulse

The central nervous system for modern logistics.

Comment

Inspiration

The inspiration for FleetPulse came from a frustrating reality I kept seeing in the logistics space: the gap between beautiful frontend prototypes and the battle-tested infrastructure required to run them in production. Too often, teams build stunning dashboards that crumble under real-world traffic, or they spend weeks wrestling with database provisioning before writing a single line of product code.

I wanted to prove that you no longer have to choose between shipping fast and shipping right. With the rise of serverless, globally distributed databases like Amazon Aurora DSQL, and edge-first platforms like Vercel, a solo developer can now architect a system that rivals what enterprise teams build in months. FleetPulse is my answer to that challenge — a logistics command center built to handle the high-stakes, high-concurrency reality of global fleet management, without sacrificing developer velocity.

What it does

FleetPulse is a real-time logistics and fleet management dashboard that gives dispatchers absolute visibility into their operations. It features:

  • Live KPI Tracking: Real-time metrics on active drivers, on-time delivery rates, delayed shipments, and fleet utilization.
  • Real-Time Shipment Feed: A continuously updating feed of active shipments with live progress indicators.
  • Comprehensive Fleet Management: Deep data tables to monitor individual driver statuses and shipment histories.
  • Geo-Aware Architecture: The app intelligently routes users to the nearest database region based on their geography, ensuring sub-50ms latency for dispatchers worldwide.

How we built it

FleetPulse is a full-stack Next.js 14 application deployed on Vercel, powered by Amazon Aurora DSQL.

Frontend: I used Vercel's v0 to rapidly scaffold a production-ready, dark-mode dashboard with glassmorphism styling, KPI cards, and a live operations split-view. This freed me to focus on backend architecture.

Edge Layer: I implemented Vercel Edge Middleware (middleware.ts) to intercept all API requests and inspect the user's country via req.geo. Based on a predefined list of EU country codes, the middleware attaches an x-dsql-region header to route traffic to the appropriate database endpoint.

Database: Amazon Aurora DSQL serves as the data layer. I used the official @aws/aurora-dsql-node-postgres-connector with IAM authentication (via @aws-sdk/credential-providers) — meaning zero static passwords in the codebase. The connection is managed through a singleton AuroraDSQLPool to prevent connection exhaustion during serverless cold starts.

API Routes: Next.js Route Handlers (app/api/shipments/route.ts, etc.) handle CRUD operations. Critical writes are wrapped in pool.transaction() to leverage the connector's built-in Optimistic Concurrency Control (OCC) retry logic.

Challenges we ran into

1. The OCC Conundrum Aurora DSQL is designed for multi-region active-active replication, which means it uses Optimistic Concurrency Control. When two dispatchers update the same shipment simultaneously, the database rejects conflicting writes to preserve integrity. The probability of an OCC conflict between two concurrent transactions can be modeled as:

$$P(\text{conflict}) \approx 1 - \left(1 - \frac{W}{D}\right)^n$$

Where $W$ is the write set size, $D$ is the total data domain, and $n$ is the number of concurrent writers. In a busy logistics dashboard, this isn't theoretical — it's a daily reality.

Initially, I tried writing manual retry loops with exponential backoff, which cluttered my API routes. The breakthrough came when I discovered the DSQL connector's built-in pool.transaction() method, which handles retries automatically. This was a major "meaningful engineering" win.

2. Multi-Region Setup Limitations I originally planned a true active-active multi-region deployment with clusters in us-east-1 and eu-central-1. However, the AWS Console UI didn't expose the linked-cluster creation flow, and the CLI approach required careful ARN construction. I pivoted to architecting the app as multi-region ready — the Edge Middleware and dynamic endpoint resolution in lib/db.ts are fully prepared for a second region; it just requires setting an environment variable.

3. NPM Package Confusion The official DSQL Node.js connector (@aws/aurora-dsql-node-postgres-connector) is relatively new, and older documentation referenced packages that no longer exist. Tracking down the correct library and its API took significant debugging.

4. Serverless Connection Pooling Vercel Serverless Functions can exhaust database connections during traffic spikes. Implementing a singleton pool pattern that persists across invocations — while still respecting IAM token refresh cycles — required careful testing.

Accomplishments that we're proud of

  • OCC-Native Transactions: Wrapping all critical writes in pool.transaction() means FleetPulse handles distributed write conflicts gracefully, with zero retry logic in the business layer.
  • Edge Geo-Routing: The middleware-based routing system is production-ready for multi-region scaling with zero code changes.
  • Zero-Trust Security: IAM authentication means no database passwords exist anywhere in the codebase or environment variables.
  • Rapid yet Robust Delivery: Using v0 for the UI and Aurora DSQL for the backend, I went from concept to a live, globally-aware full-stack app in a single weekend.

What we learned

Distributed Systems Theory in Practice Working with Aurora DSQL forced me to deeply understand the CAP theorem. Aurora DSQL prioritizes Availability and Partition Tolerance (AP), which means consistency is handled via OCC rather than locks. The tradeoff is beautifully captured by the extended CAP model:

$$\text{Latency} = f(\text{network_hops}, \text{consistency_model})$$

By routing users to their nearest region via Edge Middleware, we minimize network_hops, and by using OCC, we accept that some writes may need retries to achieve consistency — a tradeoff that works perfectly for a logistics dashboard.

Edge Computing is the Future Vercel Edge Middleware runs globally, close to the user. Combining this with a globally distributed database creates a truly low-latency experience that traditional client-server architectures simply cannot match.

AI-Assisted Development Works Best When You Know the Architecture Using v0 and Cline accelerated development dramatically, but only because I had a clear architectural vision first. AI tools are force multipliers, not replacements for engineering judgment.

What's next for FleetPulse

  • True Active-Active Multi-Region: Provisioning the linked EU cluster to enable sub-50ms database latency for European dispatchers.
  • Real-Time WebSockets: Replacing the polling-based shipment feed with Server-Sent Events (SSE) or WebSockets for true push-based updates.
  • Predictive Analytics: Using historical telemetry data to predict delivery delays before they happen, powered by AWS SageMaker.
  • Mobile PWA: A progressive web app version so drivers can update their own status in the field.
  • OIDC Migration: Fully transitioning from IAM Access Keys to Vercel's AWS OIDC integration for even stronger security.

FleetPulse is just getting started. The foundation is built — now it's time to scale.

Built With

Share this project:

Updates