In the era of COVID, everything has become virtual, including gifting. The hype behind virtual gifting has grown so much that many businesses have made it part of their business model. Apps like Moj enable and encourage virtual gifting through their virtual currency like Cheers & Mints. From hearts to cakes to a cool pair of sunglasses, a MOJ user has many choices to choose from when it comes to virtual gifting. But what else has virtual gifting enabled? Apps like MOJ & ShareChat have linked the virtual gifting functionality during a live stream and have even created games like battles.

What are virtual gifting battle services Moj & ShareChat provide?

Everyone loves a good live stream with their favorite creators or host. Sharing emojis and replies is one way to make a live stream interactive. But apps like MOJ have taken it a step further by introducing virtual gifting into live streams through SANGRAM SERVICE. It does not stop here, these social media apps took virtual gifting to another level by introducing healthy competitive games known as battles. On MOJ, there are four types of battles:

1. Gifter Battle: Here the user who sends the most gifts to the live stream creator or host within a particular period will win.
2. Opinion Battle: Here a live stream host or creator will provide users with two options. Users have to send gifts to select the option they like best.
3. Creator Battle: Here two hosts or creators conduct a battle against each other on a single live stream. Users from each live stream will compete by sending gifts. The host or creator who receives the most gifts wins.
4. Community Battle: These are task-based battles launched on popular demand.

These battles are only possible thanks to the creation of a microservice called SANGRAM SERVICE a.k.a Battle Service. It’s the one-stop solution responsible to create and support battles on a live stream. It also supports upcoming battles.

What’s the story behind SANGRAM SERVICE?

If you follow recent trends, many companies try to keep their meeting rooms, schedule, and project names based on the project functionality. The word SANGRAM means battle or war. Since this service allows users to compete or fight using virtual gifts, the name SANGRAM works perfectly for this microservice.

So, what problem does it solve?

To better understand SANGRAM SERVICE, we need to know what problem it solves. For that, we need to dive deep into this feature. One of the biggest problems this feature address is that it allows battle products to have multiple hosts in a single live stream. Just imagine the load; just like in popular games like Clash of Royales, two creators/hosts can conduct a battle on a single live stream in real-time.

Right before the battle, there are many loading screens and tasks to take care of, like finding creators, creators accepting or declining an invite, etc. Apart from the above, additionally, hosting the battle within a set duration is another matter to take care of.

This is exactly what SANGRAM SERVICE solves for; it allows all these different mechanisms to be held in real-time. Now that we know a bit more about the SANGRAM service let’s dive into the core low-level and high-level design.

How did we implement SANGRAM SERVICE’S low-level design?

To understand SANGRAM SERVICE’S low-level design, it is important to understand class diagrams and IS-A and HAS-A relationships. IS-A means a relationship between parent class and child class. Usually, it means inheritance between parent and child class. Similarly, HAS-A is a relationship between two classes where Class A has a dependency on Class B.

Now jumping back to the problem, voters battle, creator battle, etc., feature an IS-A relationship. This means that all battles inherit their main battle interface/ abstract class. Please find the image below.

Each battle has three states - start, ongoing, and end state. This means each battle will have three methods of override. Hence SANGRAM Services depicts a FACTORY-DESIGN pattern to solve this problem. Here’s a visual code snippet for better understanding.

What is the envelope of calculations behind SANGRAM SERVICE?

Diving deeper, here’s how we selected our DB schema design. We needed a service that could read multiple situations like ongoing battles, battle results, etc, for multiple battles that happened in the past, that are happening presently, and that will happen in the future. Consider read-write ratios around 100:1. Sounds confusing, right?

Imagine we have one host running a live stream and starting a battle. At this point, the DB needs to write a battle entry once. Now if 1000 viewers enter the live stream, our service will read from the DB 1000 times to display the battle status on each viewer's screen.

Let’s understand this through an example, imagine we have one host running a live stream that has 1000 viewers. If the live stream host decides to launch a battle, the DB needs to launch a screen state mentioning - Hey! Please create a new battle entry. But this would only appear for the live stream host. For the remaining 1000 live stream viewers, they need to check with the DB to see if any battle would take place.

Simultaneously, many other live streams would also be taking place. So the DB needs to work on different requests and requirements for all live stream battles. For example, there are 1 million users active on Moj, out of which there are maybe around 1000 creators or live stream hosts conducting a battle. The DB here will have to write 1000 best and worst-case scenarios for all the live streams. The DB will also have read the data from 1 million users who may be entering, exiting, or re-entering a battle.

It’s safe to say that there are a lot of heavy queries being read; of course, caching the data helps, but it’s still a very heavy database being read. That’s why it’s important to align a CAP database. It uses the CAP theorem where the CAP that supports DBs are MongoDB, Scylla, Cassandra, etc. Moj & ShareChat are supported by MongoDB because it can read the heavily documented database. As MongoDB is document-based no-sql this adds more flexibility to our service.

What are the main components of SANGRAM SERVICE?

Every battle has various intricate components involved. These components are vital because they enhance the battle experience. For each battle, the database needs to store the viewer's scores and show the result at the end. To enable this, we’ve created two microservices.

1. SANGRAM SERVICE is responsible for battles.
2. Leaderboard-service is responsible for creating a leaderboard to show scores and results.

When the host starts a battle, SANGRAM SERVICE will ask the leaderboard service to create a leaderboard unique to each live stream. Once the battle begins, it will then start allotting scores. Once the battle has ended, the service needs to end the battle automatically, so a cloud task will end the battle after the specified time. It will also generate the results and deactivate the leaderboards as well.

What are the pros and cons of the SANGRAM SERVICE?

Pro’s

1. No-SQL databases are highly scalable horizontally and vertically, therefore the DB is easily scalable.
2. SANGRAM SERVICE is written in Golang to provide high concurrency. The factory design pattern selected writes clean codes.
3. The main responsibility of SANGRAM SERVICE is to store only battle-meta. It’s possible to add an archival policy to remove the data after battle duration to save the cost. Therefore, it’s a cost-efficient service.
4. All the SANGRAM SERVICE apis p99 latencies are under <= 49ms, because of high concurrency provided by Golang, efficient indexing on Mongo DB, and archival policy.

Con’s

1. The only disadvantage of this service is that it only scales battle service. If you scale SANGRAM SERVICE then you need to scale the leaderboard service because sangram is highly dependent on the leaderboard service. The vice-versa is not required.

All in all, SANGRAM SERVICE is equipped to tackle the problems that we usually face when it comes to reading heavy codes and databases. It has also enabled our team to create an interactive experience between content creators and users. But innovation does not stop here; there’s always scope to scale up and provide users an even more interactive experience.

Team/Co-Authors: Mayank Parmar, Bhavesh Chouhan,  Akshay Agarwal, & Saurav Bains

Click here to learn more about our Engineering team