Yellow.ai has been expanding into new geographies. With these new geographies come new challenges, namely a different set of rules and regulations to abide by, and delight the end-users in the same manner as we are known for.
Thus, the geo-distributed architecture comes as a step to offer a truly distributed, global product ready to serve customers around the globe. This is mainly done through Multi-region hosting and internal architecture changes among other intricate data structures.
Note: Multi-Region hosting differs from Multi-Region routing. In Multi-Region routing, the customer is routed to the server closest to them to ensure minimal latency and enhanced connectivity. The data is cached on servers around the globe.
Multi-Region hosting ensures that the customer data is being served from a particular region. The customer may travel abroad, but the connection will still be made with the original server.
What is geo-distributed architecture?
- Physical separation of customer data across geographies.
- Separation of region-specific functionalities and webhooks used by channels.
- Seamless addition of region-specific virtual assistants.
Why geo-distributed architecture?
- Allows Yellow.ai to proactively abide by the rules and regulations concerning new territories.
- Physically separates the customer data across regions, thus ensuring that customers experience low latency.
- Provide adequate attention to the respective regions’ needs and proactively enhance the resource allocation.
One added benefit that came as a side-effect is how our services are deployed and used. Going Geo-Distributed has allowed Yellow.ai to be cloud-agnostic, thus ensuring that we are not tied to a singular partner and can better cater to our customers’ demands.
Benefits offered to enterprises
Bringing in Geo-Distributed architecture affirms Yellow.ai’s commitment to customers of providing a world-class product and service. Some of the salient benefits are:
- Provides a SaaS product that is more suited to the region’s needs.
- Enables solution deployment to any of Azure, AWS and GCP.
- Having a solution that takes region-based nuances into account.
Benefits offered to internal tech
- Moves Yellow.ai away from any cloud partner based dependencies and ensures that the products and services are usable across different cloud providers.
- Ensures that maximum regional dependencies are addressed from the same code base thus ensuring that best-in-class is the default for all regions.
- Provides avenues for enhancing Yellow.ai’s Disaster Recovery efforts as the service can be used with any cloud provider.
Compliance adherence with geo-distributed architecture
Geo-Distributed Architecture has enabled Yellow.ai to adhere to the various compliance requirements from around the world, with the most important one being the case of handling financial data. This financial data, due to regulatory and compliance requirements, cannot be stored outside the country.
Similarly, other countries have made it mandatory to store the data, irrespective of the nature, be it financial or non-financial, in a local server.
How did we do it?
There were 2 crucial steps in enabling Geo-Distributed Architecture for Yellow.ai’s platform:
- Eliminate dependency on Azure Blob Storage for storage needs.
- Modify the downstream services to call the correct region-specific upstream services.
For the first step, Yellow.ai decided to go ahead with minIO which is an object store that is cloud-native and acts as a gateway to Azure, AWS and other cloud providers object storage. This ensures that even if there is a shift between cloud providers, there will be no need to write cloud provider specific code to handle the object storage.
For the second step, the platform will remain central but the virtual assistant specific services etc will be region-specific, and the platform will take care of using the appropriate service based on the assistant’s settings. Thus, with minimal change in the settings and the deployment code, the assistant will be ready to be used in a particular region.
At the backend, the user details have been marked as global but other data is taken from the respective region’s database. Thus, if it is specific to users, then the centralised service is called, otherwise, the region-specific service will handle the query. This is ensured through use-case based routing for some routes. This also ensures that customers can log in to the centralised platform and work with different virtual assistants from a variety of regions. For end-users of the virtual assistant, there will be no change.
