Providing a Great User Experience When Expanding Internationally
CTO at MaestroQA
For most companies, the first couple of customers are their home market ones -- and ours were as well -- but we quickly acquired some other large customers in other geographies, most notably Asia-Pacific, Australia, and Europe. As a result, we started to expand our business internationally sooner than expected for a company at our stage of growth. It included not only launching the product but also providing support.
While we largely managed to deliver on expectations, there was some frustration around the increased latency of connecting to servers based in the US, entirely over the public internet. Those latency concerns would make a poor user experience. In many places of Southeast Asia, it could be up to hundreds of milliseconds slower, especially with round trips and handshakes. If activities that should be performed in fast workflows and feel quite instant are slowed down, it will start to impact the value of software. To no surprise, a customer will feel that our software is holding them back rather than accelerating them. The whole thing only adds up in time and in one’s perception that the tool is not able to follow the speed of their thoughts.
We considered multiple options. They ranged from optimizing the code to make the code itself faster, to running different versions of our entire infrastructure in different regions having one or a few hubs per continent. We also considered having some type of a hybrid system, where some parts of the systems would be located in some geographical areas while others parts would be located elsewhere. We already had a CDN (Content Delivery Network) -- which most companies with a reasonable scale do -- but there were many steps between running your infrastructure everywhere and running it in one place using CDN.
That was a direction we were set to explore and with which we got a lot of mileage. We had since been able to build up the ability to launch in specific regions, which enabled even more flexibility, particularly in regard to data residency laws. However, that didn’t come as the first obvious choice. It wouldn’t be the most feasible option in the earliest days because we were a small team with an ambitious timeframe. Running multiple data cloud centers in different places would be too much of an overhead to start with. Instead, we decided to find an intermediate option by doing some code optimization but also figuring out how to distribute better and provide a decent experience around the world.
In order to accomplish that, we looked at a couple of different tools that would benchmark our impact. We were considering moving web servers but keeping the databases in the same place. We were also looking at local points of presence from a network perspective. Ultimately, we found that it was a sufficient solution to get us started and provide a good experience for our customers.
The first step we took that got us quite far -- before going to fully distributed infrastructure -- was putting in place tools that allowed for local points of presence and networking. It could be anything from Cloudflare to AWS and its global accelerator. We looked at both solutions, and both provided significant performance improvements. Those tools would enable people to connect locally and then go to our backend over private Internet infrastructure. We could keep our backend servers in any region and a customer could connect to a server in their home country over an optimized network instead of a public Internet that could be inconsistent and slow. Though we haven’t moved all of our infrastructure into a customer’s home country, the latency would be greatly improved, especially for long-running connections, anything on Publish/Subscribe, or web socket type of architecture.
We were hesitant at first because we were convinced that the only option was to move our infrastructure all over the world. We were skeptical if that was manageable and were close to saying No to some of the customers. We pushed ourselves to think creatively and come up with a hybrid solution that would provide sufficient user experience and buy us time to develop a long-term, more sustainable solution.
When presented with problems like the one we encountered, try to understand the business impact of saying Yes. Once you establish what is the value of being able to get to Yes, start to work backward. That will force you to think creatively and solve the problem.
When looking for a clue, look at what the best and biggest companies are doing and compare that with where you are at that moment. We knew that the best players in the industry were running local infrastructure, but we had to adjust that solution to our situation. This is why we came up with a hybrid solution. Knowing the gold standard is always good, but you need to be cognizant of your constraints and find a middle ground where you will feel confident with limited resources.
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.