Soluti: architecture for a distribution center
Designed and built the complete architecture for a logistics distribution center: optimized routing, real-time tracking, and end-to-end operational traceability.
- Role
- Founder & CTO
- Industry
- Logistics
- Tech stack
- Ruby on Rails, Next.js, Flutter, PostgreSQL/PostGIS, MongoDB, NATS, VROOM, OSRM
Context
Soluti operates as a distribution center in Colombia, offering cross-docking, warehousing, and collection services for logistics operators. As founder and technical lead, I designed the entire system architecture from scratch. There was no existing platform to extend, only a real operational process that had to become reliable software from day one in production.
The challenge
A distribution center isn't a single application, but several systems that must stay synchronized under real operational pressure: back-office administration, warehouse coordinators, drivers on the road, and clients tracking their shipments, all working off the same real-time source of truth.
Three concrete problems shaped the architecture:
- Last-mile routing. Optimizing dozens of stops per vehicle isn't a textbook algorithm problem. It's a constrained assignment problem that grows combinatorially with geography and vehicle capacity.
- Shared real-time state. A driver's location, a package's status, and a route's availability change constantly and must be reflected immediately across three different applications.
- End-to-end traceability. Every package must be traceable from the moment a provider hands it off to final delivery, with photographic evidence and documents valid for billing.
The architecture
The system was designed as a multi-app monorepo: a Ruby on Rails API as the single source of truth, and three independently deployed frontends (a public landing page, an operator app, and a client app).
Routing. Instead of building a proprietary optimization engine, I integrated self-hosted VROOM and OSRM, using PostGIS for geospatial calculations and zone affinity. The engineering decision here wasn't "how do I optimize routes," it was "when does it make sense to lean on specialized tooling instead of reinventing it." The reduction in last-mile distances came from correct integration, not a custom algorithm.
Real-time. A dedicated microservice uses NATS as an event bus and MongoDB to store GPS telemetry with TTL-based expiration, keeping low long-term-value location data from bloating the primary database.
Mobile. The driver app was built in Flutter, with background GPS, barcode scanning, and in-route package synchronization, using Riverpod for state management and go_router for navigation.
Traceability. The data model covers the full chain, from Provider to Operation, Shipment, Package, and Route, with billing-ready document generation and photographic evidence stored in self-hosted MinIO on OVH.
Decisions that made the difference
- Prioritizing proven routing tools (VROOM/OSRM) over building a custom solver, freeing up engineering time for the rest of the system.
- Separating real-time state (NATS + MongoDB with TTL) from transactional business data (PostgreSQL), so a scaling problem in one wouldn't affect the other.
- Designing traceability into the data model itself, not bolting it on as a reporting layer afterward.