While working with our team dedicated to one of our internal projects BeThereNow, we identified a challenge: to know the payload size returned by our microservices. In this article, I explain briefly about BeThereNow, the associated challenge, and how we solved the challenge.

What is BeThereNow?

If you haven’t checked out our BeThereNow product, you should. BeThereNow is a digital sales accelerator that allows effortless and affordable creation of virtual tours with no technical skills required at all. It empowers you to engage your audience with interactive, audio guided and high-quality lifelike tours that sell 24/7 online. Simply send a link instead of dealing with no shows or inconvenient appointments set at 7 am or 7 pm. Forget needing professionals, special equipment, production staff or even coding skills – all you need is a browser and marketing skills. Our software does everything else for you. Always on the go? You can even edit your tours on your mobile phone on the way to your next meeting. You can even create “rooms” and add content to them such as videos, pictures, and links. You can also link rooms together, so users can essentially “walk” through your environment.

When embarking on efforts to develop BeThereNow, we had little idea about the applications our product will be able to deliver to the end consumers. Today, BeThereNow offers a powerful new way of marketing products to versatile customers including real estate, automobile and event management players. Check for yourself.

The Assemblage (Real Estate)

Regus One Rock (Real Estate)

Maserati (Automobile)

Hackathon (Event Recap)

Microservices Architecture

The microservices architecture runs on Google Kubernetes Engine (GKE) in Google Cloud Platform (GCP). The UI is written in Angular 5, and the back-end leverages Spring Boot and Spring Cloud. Most of the data is stored in MongoDB. When a scene is loaded, the API returns an XML document that contains all the information about the scene. The UI knows how to translate this XML and build out the VR interactive tour.

The Challenge

We were exploring potential opportunities to monetize the product. The most obvious way of monetization was to charge against the number of rooms and amount of information that a user adds to their scene. Notably, the API returns the entire scene in one shot; the more rooms, endpoints, and hotspots you add, the bigger the payload is going to be. Each scene also has a key used to identify it. In effect, we had to ensure that scene1 built by user A does not overlap with scene2 built by user B. Therefore, the requirement was to calculate the charges based on the passed key.

Another problem that we discovered was that the payload size could essentially change for each time it is called. Think of this scenario. A user creates a scene with two rooms and sends it out to many people to view. Later, they decide to add another room. Adding another room will increase the payload size and thus change the overall size of all requests, making it more complicated. Moreover, our customers’ visibility of the bill rendered and stated was at stake.

Metrics for Cloud Microservices

In the initial stage, we thought we could leverage some of the existing APIs that run in the cloud. The team reckoned that Apigee or Cloud API would be a simple solution. We were surprised to find out that this wasn’t possible for a key-by-key requirement. Some of the APIs were able to return several requests to another API, but the actual payload size was challenging to fetch. Although this may be true that there is an API we missed, these tasks of filtering by key, like many in manual grade, are labor—intensive and expensive.