Skip to content

What is DMS

The physical system

The Flexli mSort system is a warehouse conveyor belt sorter. When a parcel is placed on the belt:

  1. A barcode scanner reads the AWB (Air Waybill number) from the label
  2. The DMS looks up where that parcel should go (routing decision)
  3. The DMS drives a physical sort bin or robot to the correct drop position
  4. 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