Gura, A Powerful Video Conferencing Software Connecting Agents with Shoppers
Updated: Aug 21
Hi, everyone, I'm Wenjie, the CTO of Gura, and today we will talk about how we built Gura.
Gura is a two-sided marketplace for online shoppers and brick-and-mortar retailers, or online retailers, to sell more products with the enhancement of live video or audio.
Our technology supports at minimum the following functionalities
On-demand customer agent matching by
Customer and agent can communicate via video or audio meeting with product information in the meeting viewport
Customer and agent can chat in text
All of the video session data, such as recordings, chat, metadata, are persisted and queriable for analytics and analysis
Add-to-cart button in the meeting that signals a conversion event
Some natural extensions that it should support easily in the future are
Matching using contextual information
Add-to-cart button will add the product to the cart directly
The two-sided marketplace is modeled by states for both client and agent. When the client makes the video request, we create a new Task, and the client state starts from REQUESTED. We then publish a Kafka event that is subscribed by the meeting broker. The broker looks at the pending task, and all active agents, and matches the task to the best agent by organization, agent specialties. Broker can deploy different matching strategies including the one that uses Machine Learning to incorporate contextual features in the future. If an agent is assigned, the agent is notified in two phases. The first phase is a notification in the Gura portal; the second phase is a phone call. The phone call only happens if the agent doesn’t respond to the meeting request within a fixed period of time.
Once assigned, the agent state becomes ASSIGNED. When the agent joins the meeting, the agent state changes to WIP. A background controller listens to such state change and changes client state to WIP as well. Both client and agent state changes are always pushed back to their devices via websocket, so that states can reflect in the presentation layer change immediately. Because both client and agent state are transitioned independently and orchestrated by the controller, we can easily extend our business logic such as asking client to leave a contact, if the agent didn’t respond for an extended period of time.
We synchronize state changes across devices by implementing our own lightweight document synchronization library via Websocket. State changes are pushed to devices as key value pairs. Devices can register custom processors / functions based on the key. We use this to modify all kinds of on-device states in a unified interface.
We designed the service to be scalable to millions of users or more, and endless verticals of buyers and sellers. Whether it’s personal goods, real estate, wine, cars, or others.
Brokers are modeled as Kafka consumers, and consumer groups can be partitioned by organization group hashes. This allows us to balance the workload per broker. Client and agent listen to state changes via different Kafka topics and filter on its own ID to consume relevant messages. All states are also persisted in a distributed NoSQL database, which can also be partitioned by organization.