What is DMS¶
The physical system¶
The Flexli mSort system is a warehouse conveyor belt sorter. When a parcel is placed on the belt:
- A barcode scanner reads the AWB (Air Waybill number) from the label
- The DMS looks up where that parcel should go (routing decision)
- The DMS drives a physical sort bin or robot to the correct drop position
- The parcel is ejected into the right bin
The DMS is the software that runs steps 2–4. It runs on a server inside the warehouse, communicating with the scanner hardware over TCP/MQTT and with partner APIs over HTTPS.
Two-layer architecture¶
┌──────────────────────────────────────────────────────────────┐
│ Core Layer (msort schema) │
│ │
│ ScannerService ──▶ IClientService ──▶ BinService │
│ │ │ │ │
│ InfeedService (strategy seam) BotService │
│ │ │ │ │
│ SessionService MeeshoService StationService │
└───────────────────────────┼──────────────────────────────────┘
│
┌───────────────────────────▼──────────────────────────────────┐
│ Meesho Layer (meesho schema) │
│ │
│ MeeshoHttpClient ──▶ DataSyncWorker ──▶ data_sync table │
│ TokenRefreshWorker ──▶ bearer token cache │
│ OutboxWorker ──▶ inscan_sync + motherbag_sync tables │
└──────────────────────────────────────────────────────────────┘
Core Layer — tenant-agnostic. Handles scanner I/O, bin state, bot control, session management. Lives in the msort PostgreSQL schema.
Meesho Layer — client-specific integration. Polls Meesho's API for AWB routing data, pushes InScan + manifest notifications back. Lives in the meesho PostgreSQL schema.
The IClientService interface is the seam between them — swapping clients means providing a different IClientService implementation, not forking the codebase.
Where DMS fits in the Flexli platform¶
graph LR
Scanner["Barcode Scanner\n(Cognex / TCP)"] -->|AWB scan| DMS
DMS["DMS\n:5269"] -->|routing lookup| Partner["Partner API\n(Meesho / Myntra...)"]
DMS -->|bin/bot command| Hardware["Sort Bins\nRobots\nConveyors"]
DMS -->|audit + outbox| PG["PostgreSQL 16\ndms-layered"]
Partner -->|AWB data| DMS Key design decisions¶
| Decision | Why |
|---|---|
| One codebase for all clients | No customer branches — client variation is handled at deployment time via tenant manifest (RFC FLX-ENG-RFC-001) |
| PostgreSQL over MongoDB | Relational FK constraints enforce routing consistency; EF Core migrations are version-controlled |
| Outbox pattern | InScan + manifest notifications to partner APIs are written to DB first, then drained by workers — survives network partitions |
FOR UPDATE SKIP LOCKED | Concurrent outbox workers drain different rows without blocking each other |
| Partial unique index on sessions | WHERE state = 'Active' — exactly one active sort session at a time, enforced at DB level |