Hyper Resilient

We have decades of experience building reliable, successful enterprise applications.

Many technologies have come and gone over the years, while our choices have stood the test of time. Our resilience is because we have spent months and even years chasing down difficult problems from router & networking issues to ISP and cloud issues.

This has allowed us to find the root cause of many problems, and figure out solutions where our software can run in the harshest of environments, including Black Friday & Cyber Monday peaks.

We don't give up. We never give up. We keep at it, till a solution is found - even if it takes weeks, months or years. And if the vendor cannot find the solution or debug the issue, we debug the issue and find the solution ourselves.

The solution is never to upgrade to a more expensive, higher tier of cloud services - it is to build resilient software which can handle scenarios like high network latency seamlessly. Even expensive systems fail at some point - the right solution is to handle it within software.

• Our software is designed to run on the smallest cloud resources with 2 cores and 8GB RAM.
  • These resources have high Disk I/O
  • These resources also have high network latency with occasional outages.
  • Our goal, inspired by Google has always been to run on the cheapest cloud resources, as long as possible and scale up horizontally.
  • We only recommend scaling up elastically or when there is genuine need like sustained high CPU usage because of heavy load, or low memory which can also happen when more data is cached.


• We have first hand experience of scaling up massively using all the third party technologies we use internally.
  • We have deep relationships with these vendors having debugged and resolved many major scalability issues in the past.
  • Our internal frameworks and APIs take full advantage of our deep expertise in technologies like MongoDB, Redis & Azure Cognitive Search.


• We have successfully debugged and resolved very hard production issues where others have tried and failed before.
  • High network usage caused services to be restarted in production every few hours.
  • Applications which fail to run properly on one of many servers with identical hardware.
  • A complete failure of the .NET Framework because of code size and complexity.
  • Applications which consumes so much CPU that the machine is unusable for anything else.
  • In one case, we debugged an issue with an ISP connection for over a year, and they had to send personnel onsite to replace the SFP+ module, a few days before complete failure of Internet connectivity.


• We have advanced logging and health detection capabilities which allow us to debug issues which happen on random servers at random periods of time.
  • These capabilities have been built after years of experience debugging hard issues and finding solutions where third party support had given up, but we did not.