Abhishek Mishra
CTO, Sort String Solutions
When people hear that SalesPort processes 12 Lakh transactions every day across 45 companies, the first question from any technical person is: how? This post walks through the architecture decisions, scaling challenges, and engineering trade-offs behind SalesPort's infrastructure. It is written from a CTO's perspective — not marketing fluff, but the actual decisions we made and why.
The scale we are operating at
Before diving into architecture, here are the real numbers from our production platform today. 45 companies running simultaneously on dedicated instances. 2.3 Lakh active users across those deployments. 30,885 B2B orders processed per day. 5.9 Lakh GPS check-ins captured per day. 21.64 Crore GPS data points tracked in total. ₹8,572 Crore of annual GMV. 83,785 farmers connected. 1,797 Village Level Collection Centres.
Each of these 45 companies has its own data silo, its own business rules, its own scheme logic, its own hierarchy of distributors and territories. And it all has to work at 5:30 AM when the morning shift starts at every dairy collection centre in Uttar Pradesh, Bihar, Rajasthan, and the Nepal border simultaneously. Scale is one thing — simultaneity is another.
Why offline-first matters more than anyone admits
India's distribution happens in areas where 4G is a luxury. A milk collection agent at a Village Level Collection Centre in rural Bihar cannot wait for a network signal to record a farmer's collection. A field salesperson in a dusty market in interior Madhya Pradesh cannot load a web page to book an order. A delivery driver on a highway between two towns has spotty connectivity for 40 kilometre stretches.
Standard SaaS distribution platforms are built cloud-first: every action is a round trip to a server. That model works in Mumbai and Bangalore. It fails everywhere else. The SalesPort mobile app stores all data locally in a device-level database, queues transactions, resolves conflicts deterministically, and syncs when connectivity returns. This is not a nice-to-have feature — it is the core architectural decision that makes the platform viable for Indian distribution. Anything less, and the field team reverts to paper within the first week.
The tricky part is conflict resolution. When a milk collection agent records 42.3 litres from farmer X at 5:47 AM offline, and the finance team simultaneously updates farmer X's bank account details online, both changes must merge correctly when the device syncs. We use a last-write-wins strategy for mutable fields and an append-only log for transactions. It is not glamorous. It works.
Dedicated instances vs multi-tenant SaaS
Unlike SaaS platforms that run all clients on shared infrastructure, each SalesPort deployment is a dedicated instance. This means the client data never co-mingles, performance issues with one client do not affect another, and customisation is effectively unlimited. The trade-off is operational overhead — we manage 43 separate deployments, each with its own database, its own backups, its own monitoring dashboards.
Is this the SaaS textbook? No. The textbook says multi-tenant is the only sensible way to scale. But for a client processing ₹646 Crore of annual procurement (our largest), data isolation is non-negotiable. A bug in another client's custom workflow should never have the possibility of touching their data. A dedicated instance makes that guarantee structural rather than procedural.
The dairy challenge: real-time quality testing at scale
Milk procurement adds a dimension no other distribution platform in India handles: real-time quality data at the collection point. Every collection records the farmer ID, the litres, the fat percentage, the SNF (Solids-Not-Fat) percentage, and calculates the payment amount automatically based on a quality-based pricing table that each dairy configures differently.
Across 1,797 Village Level Collection Centres, that works out to 3.27 Crore milk collection records processed historically. At peak morning collection (5:30 to 7:30 AM), we are handling thousands of quality measurements per minute across geographically dispersed collection centres — most of them on offline devices that will sync later. The pricing tables themselves are dairy-specific and often territory-specific within a single dairy.
The payment calculation is deterministic: given the litres, fat, SNF, and the pricing table, the amount is fixed. But the pricing tables change — for seasonality, for farmer incentive programs, for regulatory reasons. Versioning those tables and ensuring that a 5:47 AM offline collection is priced against the correct version of the pricing table when it syncs later is the kind of boring engineering that only matters when you do it wrong.
What we are building next
AI forecasting for demand prediction based on historical order patterns. Advanced MIS dashboards for real-time decision-making by operations heads. A cloud analytics layer for clients who want enterprise BI without pulling data into a separate warehouse. Smarter anomaly detection on GPS traces to catch fake visits more reliably.
We are also investing heavily in developer tooling — better local dev environments, better test coverage for the offline sync logic (which is notoriously hard to test), better deployment automation for the growing number of dedicated instances.
The takeaway for technical evaluators
If you are a technical decision-maker evaluating distribution software for an Indian dairy, FMCG, or agri business, the questions that matter are: Does the mobile app actually work offline? Is your data isolated or shared? Can the platform handle your peak load (morning collection, month-end dispatch, festival season orders)? Is the pricing transparent enough to plan a 3-year total cost of ownership? Does the architecture match how your business actually operates, not how a textbook says SaaS should operate?
I am happy to walk through SalesPort's architecture in detail for any technical evaluator — drop me a message via the demo page and I will make time for a technical deep-dive.