Durable freight matching is a systems problem, not a database query—it needs proximity, capacity, schedule, ETA, and time-window logic working together, plus tolerance for messy real-world data.

Corazor Technology designed and built Trulogist end to end: a real-time road-freight marketplace that connects customers, transporters, and drivers across three dedicated mobile applications and a production Node.js backend. Corazor owned the full stack—architecture, matching logic, all three React Native apps, test coverage, and the CI/CD pipeline to Azure.

The flagship capability is a return-freight matching engine that fills empty return trips with real customer demand—converting dead-haul miles into revenue while keeping strict driver assignment, real-time status propagation across every app, and a hardened deployment pipeline. See our web platform engineering and mobile work.

About the Client

Trulogist operates a three-sided logistics marketplace with dedicated apps for customers who book goods movement, transporters who own fleets and assign drivers, and drivers who execute trips. The platform handles the full lifecycle: load discovery, quotation, negotiation, driver assignment, live tracking, OTP-verified trip start, and completion. Its business model earns margin on matched freight, with return-freight loads priced lower for customers while improving transporter economics.

The Challenge

Trulogist needed a complete, production-grade marketplace built from the ground up—three role-specific apps, a real-time backend, and the operational plumbing to run live freight. The defining commercial problem was empty return miles: when a transporter completes a booking from X to Y, the truck frequently returns empty from Y to X, a dead haul that erodes margin and wastes capacity. Trulogist wanted to convert those return legs into revenue at a lower, still-profitable price point.

Turning that idea into a reliable product surfaced hard constraints. Matching is not a simple reverse lookup—a useful match must consider proximity rather than exact points, truck type, available capacity, driver schedule overlap, ETA, and a bounded pickup window. Real-world data drifts: truck types were entered inconsistently (14ft, 14 ft, 14_ft, 14-ft), silently breaking valid matches. Assignment integrity matters, because a return-freight ride depends on a specific pre-committed driver taking the load. Status changes had to propagate instantly across customer, transporter, and driver apps to avoid contradictory states. And the delivery pipeline had to survive real-world failure conditions like third-party registry outages.

The stakes were high: a matching engine that only mostly works is worse than none, because a missed or wrong match damages trust on all three sides of the marketplace.

"Durable freight matching is a systems problem, not a database query—it needs proximity, capacity, schedule, ETA, and time-window logic working together, plus tolerance for messy real-world data."

Corazor Editorial

Platform Engineering

❞

Why Corazor

Trulogist chose Corazor for outcome ownership under one accountable team spanning architecture, build, quality, and deployment—rather than a staff-augmentation model where matching logic, mobile apps, and DevOps sit with different vendors. The engagement was framed around production-grade delivery, not demos: strict correctness in the matching engine, real-time integrity across apps, and a deployment pipeline that survives real failure conditions. New capability was governed feature-by-feature behind a feature flag before being scaled to all traffic. Explore our services across build and architecture.

Our Approach

Discovery. We designed the full ride lifecycle—creation, quotation, negotiation, assignment, tracking—and identified exactly where return-freight priority should intercept it. The decision: return-freight matching runs first, and only falls back to a nearby-driver search if no return match is found, preserving a proven default flow.

Design. We modeled return freight as a first-class entity—a ReturnFreightRequest capturing route, mapped driver, vehicle, schedule, and available capacity. Rather than a rigid reverse-geocode match, we chose soft geofencing (a roughly 50 km radius) plus a plus-or-minus 24-hour arrival window, balancing match rate against relevance.

Build. We implemented the matching engine with layered filters—geo-radius, truck-type candidates, capacity, driver schedule overlap, and ETA awareness—and integrated it into ride creation behind an ENABLE_RETURN_FREIGHT_PRIORITY feature flag for controlled rollout. Read our SaaS development process guide for how we sequence delivery.

Hardening. As real usage exposed edge cases, we added truck-type normalization, richer match diagnostics that log exactly why a slot was rejected, strict mapped-driver assignment, and an auto-retry so a locked ride assigns the moment its mapped driver becomes available. We introduced idempotency keys on assignment to prevent duplicate operations.

Launch and handoff. We built the CI/CD pipeline for speed and reliability and delivered integration tests as living documentation of the matching contract.

The Solution in Detail

Architecture and stack: a Node.js and Express backend with Socket.IO for real-time events across the three apps; MongoDB via Mongoose using geospatial coordinates for proximity matching; Joi request validation, JWT auth, and role-based access control for customer, transporter, and driver; centralized error handling and idempotency middleware on critical write paths. The three customer, transporter, and driver apps were built in React Native (Expo) sharing real-time socket contracts, deployed through GitHub Actions CI/CD to Azure App Service.

Return-first matching with safe fallback: ride creation attempts return-freight matching before the nearby-driver search, so the new capability never regresses the existing experience. Resilient matching against real-world data: a normalizeTruckType and getTruckTypeCandidates layer collapses formatting variants and queries with an inclusive set, eliminating a whole class of silent match failures. Match attempts emit structured diagnostics—missingDriver, truckTypeMismatch, busyDriver, reverseRouteMiss, etaMiss—so operators can see why a match did or did not happen.

Strict mapped-driver assignment: for return-freight rides, only the pre-committed driver is eligible; manual assignment of any other driver is explicitly blocked, and if that driver is momentarily offline the ride enters a controlled waiting state. Availability-triggered auto-assignment: rather than assigning only once at acceptance, the system re-attempts assignment whenever the mapped driver becomes eligible—on location update, availability change, or ride completion—using a transactional lock (online, available, fresh location, no other active ride) to prevent double-booking. Real-time state integrity: acceptance and assignment emit ride-updated, driver-new-ride, driver-details, and driver-assigned events to all relevant parties, keeping every view consistent.

Quality and delivery hardening: integration tests in Jest cover the matching contract, including reverse-route hits, single-slot fallback, and rejection of slots outside the time window. The CI/CD pipeline was built on npm ci with dependency caching, pinned to the official npm registry with retry and backoff after a mirror outage broke deploys, and given concurrency control to cancel stale runs and prune dev dependencies from the deploy artifact.

Results & Impact

Corazor delivered a complete, production-grade freight marketplace: three real-time mobile apps, a hardened backend, and a return-freight matching engine with observable diagnostics rather than a black box. Truck-type normalization eliminated an entire class of silent match failures. Real-time consistency across the three apps removed contradictory ride states. Strict single-mapped-driver assignment with duplicate-safe idempotency protected the marketplace's core promise. And a faster, more reliable deployment pipeline made releases resilient to third-party registry outages.

Feature-flagged rollout let Trulogist validate return-freight on real traffic before scaling it platform-wide. As the marketplace grows, Corazor and Trulogist are instrumenting the outcomes that matter most—the share of return legs matched to revenue, match reliability, and deployment performance—so future results can be reported with measured evidence. See our guide on product architecture for scale for related patterns.

Key Takeaways

Matching is a systems problem, not a query—durable freight matching needs proximity, capacity, schedule, ETA, and time-window logic working together, plus tolerance for messy real-world data. Instrument the no-match path: structured diagnostics on rejections turn an opaque "no drivers available" into a debuggable, improvable system. Correctness beats reach for high-trust flows: strict mapped-driver assignment with idempotency protects the marketplace's core promise. Deployment reliability is a feature: pinning registries, caching, and retry logic prevent external outages from blocking releases. And shipping behind a flag lets you scale confidence before scaling traffic.

Conclusion

If your marketplace or logistics platform needs a matching engine and delivery pipeline built to production standards—owned end to end by one accountable team—Corazor Technology designs, engineers, and ships it from architecture through deployment. Talk to Corazor about your platform.

Corazor Editorial