The challenge
Kanish ran 140 vendors on a heavily customised open-source platform. It functioned on ordinary days and collapsed during every promotional campaign, typically at around 3,000 concurrent users. The last festival sale had eight hours of downtime during the highest-traffic window of the year.
Vendor settlement was calculated manually in spreadsheets and took eleven days after month end, which had become a recurring source of vendor disputes.
What we built
We rebuilt the platform on ASP.NET Core with Next.js on the storefront, moving search to Elasticsearch and putting Redis in front of catalogue reads. Checkout was redesigned around idempotent payment capture with automatic gateway failover.
Vendor settlement became an automated pipeline: commission rules per category, automatic TCS deduction, and a settlement cycle vendors can watch in their own dashboard.
How we delivered it
We ran the new platform in parallel with the old one for six weeks, mirroring a percentage of live traffic to validate behaviour under real load before any customer was moved.
Load testing was the decisive phase. We tested to 25,000 concurrent users and found two bottlenecks that would not have appeared in staging: a database connection pool limit and an unindexed query on the vendor payout table that only degraded above roughly 8,000 sessions.
The results
The platform handled 22,000 concurrent users during the following festival sale with no downtime and a median page load of 1.1 seconds. Gross merchandise value for that campaign rose 3.4 times over the previous year.
Vendor settlement now completes in under two hours after month end rather than eleven days, and settlement disputes have effectively stopped.
We had been told the traffic was the problem. It turned out the architecture was the problem, and the traffic was just revealing it.